Кэширование в SQLOS

 По материалам статьи Slava Oks: SQLOS Caching

Эта статья рассказывает о том, как изменился механизм кэширования в SQL Server 2005.

Отличия в кэшировании 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.

-------------- ------------ | Cache Store | | User Store | --------------\ /------------ \ / \/ ---------------- |Clock Algorithm | ---------------- | ------------- | Clock Hands | ------------- | ----------------- |Clock Entry Info | ----------------- Рис. 1

Концептуально для кэшей 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, чтобы можно было улучшить управление каждого отдельного кэша или группы кэшей.

Хранилище объектов

Хранилище объектов (Object Store) представляет из себя обыкновенный пул. Оно используется в качестве кэша гомогенных типов данных. В настоящее время для этого типа хранилища не используются какие - либо оценки, связанным с его элементами. Object Store отслеживает максимальную ёмкость, что используется для управления его размером относительно других кэшей. В дополнение к описанным в предыдущих статьях оповещениям Resource Monitor о вытеснении памяти, Object Store умеет сокращать установленное при начальной конфигурации число элементов. В будущем можно будет реализовать более сложные алгоритмы, а пока мы хотели бы оставить всё это простым настолько, насколько это возможно.

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 постоянное руководство перемещениями, Вы можете повысить производительность сервера, найдя способы сократить их число.

Следующая статья

В моей следующей статье я попробую проанализировать разные ошибки, связанные с недостаточностью памяти (OOM). Я также намерен показать способы, позволяющие избежать погружения сервера в разного типа вытеснение памяти.
Я надеюсь, что эта статья окажется для Вас полезной. Пожалуйста, присылайте мне ваши комментарии.