Кешування в SQLOS
Кешування в SQLOS
За матеріалами статті Slava Oks: SQLOS Caching
Відмінності в кешуванні SQL Server 2000 та SQL Server 2005
Управління пам'яттю SQL Server 2005 відрізняється від SQL Server 2000 складнішою структурою кешування. У SQL Server 2000 реалізовано два основні кеші: кеш сторінки даних, званий Buffer Pool, та кеш процедур, кеш планів виконання запитів. Buffer Pool та кеш процедур дуже сильно пов'язані між собою. Наприклад, кеш процедур використовує механізм виселення буферного пулу, щоб керувати його розміром, незважаючи на те, що обидва кеші мають власні політики оцінки. Використання пов'язаних BP і кешу процедур значно спрощує механізм кешування SQL Server 2000, з яким ми зазвичай маємо справу при вирішенні проблем. Ця модель дуже добре працювала в SQL Server 2000, але вона непридатна для SQL Server 2005. З появою в SQL Server 2005 нових функціональних можливостей та нових вимог з'явилася необхідність збільшення числа кешів. Зв'язок усіх кешів з Buffer Pool став не тільки проблематичним, але навіть нездійсненним. Стало очевидним, що ми маємо створити загальну структуру кешування. Ключовою ідеєю цієї структури є однорідний механізм та загальна політика оцінки.
Загальна структура кешування
Для кешів різних типів даних SQLOS використовує загальну структуру кешування. Реалізовано кілька типів механізмів кешування: Cache Store, User Store та Object Store. Кожне таке сховище має власні властивості і, отже, по-своєму використовується. User Store – це трохи незграбна назва для кешу, але коли я опишу його застосування, Ви зрозумієте логіку такого іменування. Перш ніж приступити до опису сховищ, я хотів би пояснити відмінності між значеннями кешівта пулів. У середовищі SQLOS кеш - це механізм кешування гетерогенних типів даних із заданою для кожного елемента оціночною вартістю. Зазвичай існує заданий стан, що з елементом. Кеш керує елементом протягом усього часу його існування, його видимістю та реалізацією одного з типів політики оновлення кешу – Least Recently Used (LRU). Залежно від типу даних, елементи, що кешуються, можуть одночасно використовуватися кількома клієнтами. Наприклад, кеш процедури SQL Server також є в термінах кешем SQLOS. Весь життєвий цикл плану, його видимість та оцінка управляється механізмом кешу SQLOS. Кожен з планів, що кешуються, може одночасно використовуватися кількома пакетами. У свою чергу, пул, у термінах SQLOS, це механізм кешування гомогенних даних. У більшості випадків дані, що кешуються, не мають ні стану, ні оцінки, пов'язаних з ними. Пул управляє життєвим циклом елемента лише цілком, як та її видимістю. Коли елемент витягується з пулу, фактично він з нього видаляється, і пул перестає ним як-небудь керувати, поки цей елемент знову не потрапить до пулу. Одночасно елемент може використовуватися лише одним клієнтом. Прикладом такого пулу може бути пул буферів мережі: без станів, без оцінки і його буфери одного розміру. Майте на увазі, що Buffer Pool у SQL Server у термінах SQLOS є кешем. В даний час він не використовує жодного механізму кешування SQLOS.
Cache Store та User Store
Обидва сховища є фактично кешем і дуже схожі. Використовувані раніше такі інструменти, як хеш-таблиці і визначення останніх користувачів, що зажадали кеш, були вдосконалені розробниками, в результаті чого була створена нова структура, що має власну семантику пам'яті, іотримав назву User Store.
Концептуально для кешів SQLOS представлені два основні види контролю – управління життєвим циклом та управління видимістю. Управління життєвим циклом здійснює керування елементом протягом його життя в кеші. Управління видимістю здійснює керування видимістю елемента. Важливо зрозуміти, що елемент може існувати в кеші, але водночас невидимий. Наприклад, якщо кеш відзначений лише для одноразового використання, елемент не буде бачити після його використання. Крім того, елемент може бути позначений як брудний. Такі елементи, як і раніше, продовжують існувати, жити, в кеші, але при пошуку вони нікому не будуть видно. Протягом усього життя елемента, механізми сховища керують ним самостійно. У випадку Cache Store весь життєвий цикл елемент знаходиться повністю під управлінням структури кешування SQLOS. У випадку User Store, час життя елементів керується сховищем лише частково. Оскільки користувач використовує власний механізм використання пам'яті, він також бере участь у керуванні життям елемента. Для обох випадків, видимість елементів сховища знаходиться під керуванням структури кешування. Протяжність життя елемента управляється за допомогою вбудованих лічильників для посилань - Clock Entry Info. Як тільки цей лічильник дійде до нуля, елемент буде видалено. У випадку User Store буде видалено лише Clock Entry Info, а не реальні дані. Видимість елемента визначається пін - лічильником, вбудованим у Clock Entry Info. Майте на увазі, що пін – лічильник та лічильник посилання – мають різні механізми. Один керує тривалістю життя, а інший видимістю. Щоб елемент був видимим його пін - лічильник повинен відповідати видимості, маючи значення, що перевищує нуль.Елемент не повинен вважатися брудним і не повинен бути помічений для одноразового використання. Пін – лічильник єдиний засіб, що показує, що елемент бачимо і в цей момент не використовується.
Механізм сховища кешу має власну пам'ять - хеш-таблиці. Одне сховище кешу може мати кілька хеш-таблиць. Це дуже корисно, коли сховища кешу користувачів мають підтримувати кілька типів пошукових запитів. Наприклад, кеш процедур SQL Server експлуатує ці функціональні можливості, коду необхідно забезпечити процедурам пошук на ім'я або ідентифікатор. Процес пошуку в різних хеш-таблицях незалежний один від одного і не суперечить процесам синхронізації, описаним нижче.
Структура кешу SQLOS для управління видимістю та життєвим циклом елементів кешу реалізує політику LRU. Моделювання LRU необхідне реалізації алгоритму синхронізації (Clock Hands). Об'єкт Clock Algorithm є і в сховищах Cache і User Store. В даний час існують дві можливості для Clock Hands: внутрішнє керівництво та зовнішнє. Зовнішній посібник виконує Resource Monitor, і він необхідний, коли витіснення пам'яті піддається процес цілком. ( http://blogs.msdn.com/slavao/archive/2005/02/19/376714.aspx) Внутрішнє керівництво синхронізацією використовується для керування розміром кешу щодо інших кешів. Ви можете думати про внутрішні Clock Hands, як про шлях відстеження максимальної ємності кожного кеша. Якби цього механізму не було, тоді була б можлива ситуація, коли один кеш може занурити процес у витіснення пам'яті. Наприклад, якщо ви виконуєте багато спеціальних запитів, вони можуть кешуватися. Не маючи внутрішнього керівництва синхронізацією, вони могли б занурити у витіснення пам'яті весь SQL Server.Щоб уникнути цього, внутрішнє керування почне запускати переміщення, якщо структура кешування визначить, що кеш процедур досяг максимальної ємності. Основне Clock Hands переміщення не впливає на роботу сховища. Щоразу, коли на якомусь кроці синхронізації в Clock Hands виявляється, що елемент ніким не використовується, його оцінка ділиться на 2, а якщо елемент не використовується, і його оцінка дорівнює нулю, Clock Hands спочатку зробить елемент невидимим, а потім спробує видаляти його із кешу. Процес видалення може закінчитися невдало, якщо існує інший Clock Hands, який в той же час працює з елементом, що видаляється. Як тільки обидва Clock Hands закінчать використовувати елемент, його буде видалено. Можливо, що в майбутньому ми розробимо більше різних Clock Hands, щоб можна було покращити керування кожного окремого кешу або групи кешів.
DM-подання сховищ та контроль заповнення кешів
DM-подання (dmv) SQL Server 2005 дають Вам можливість відстежувати поведінку кешу під час його використання. У Beta 2 їх було дуже багато, і вони представляли інформацію про сховищах: sys.dm_os_memory_caches і sys.dm_os_memory_pools. У Beta 3 Ви можете побачити ще кілька таких уявлень:
sys.dm_os_memory_cache_counters - надає підсумкову інформацію по кожному сховищу, наприклад: обсяг пам'яті, кількість елементів, кількість використовуваних елементів і т.д.
sys.dm_os_memory_cache_hash_tables - надає інформацію про хеш-таблицях сховища кешу, таку, як: максимальна, мінімальна та середня довжина ділянки пам'яті і т.д.
sys.m_os_memory_cache_clock_hands - надає інформацію про Clock Hands у розрізі кожного кешу та сховища користувача: активність Clock Hands, число раундів,кількість віддалених елементів тощо.
Ці динамічні уявлення дуже корисні розуміння роботи кешів, їх контролю та налаштування поведінки окремого сховища чи всього SQL Server. Наприклад, якщо Ви спостерігаєте для Clock Hands постійне керівництво переміщеннями, Ви можете підвищити продуктивність сервера, знайшовши способи скоротити їх кількість.