Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#258<< #259 |
СОДЕРЖАНИЕ Менеджер памяти SQLOS: диагностика вытеснения памяти
По материалам статьи Slava Oks:
SQLOS's memory manager: responding to memory pressure
При настройке SQL Server очень важно понимать, как он реагирует на вытеснение памяти.
Автор уже посветил довольно много времени на описание разных типов вытеснения памяти.
В этой статье Вы узнаете, почему это так важно. Вытеснение памяти можно классифицировать
двумя основными группами: вытеснение VAS и вытеснение физической памяти. Вытеснение
физической памяти может быть спровоцировано операционной системой, мы назвали его внешним,
или оно может быть спровоцировано процессом, такое вытеснение мы называем внутренним.
Resource Monitor и Memory Clerks
Вспомним, что в SQLOS имеются два типа узлов: узлы памяти и процессора. Узлы памяти
обеспечивают место для распределения, а узлы процессора предоставляют места для
планирования. В текущей реализации каждый узел процессора имеет собственный монитор
ресурса (Resource Monitor). Это нужно для того, чтобы быть обеспечить реакцию на
вытеснение памяти для узла. Автор расскажет более подробно об узлах процессора, когда
перейдёт к рассмотрению подсистемы планирования SQLOS. Пока же нужно уяснить, что в
зависимости от аппаратной конфигурации одновременно может исполняться несколько задач RM.
С точки зрения планирования у RM есть несколько важных вещей, о которых стоит знать:
Некоторые клерки памяти могут реагировать на вытеснение памяти. Мы уже упоминали кэши, но кроме них, ещё и каждый узел процессоров понуждает своего клерка ограничивать работу исполнителя (worker) и урезать системные пулы потока, который подвержен вытеснению. К примеру, полнотекстовый поиск, в таких случаях, даёт команду своему клерку памяти на сокращение разделяемых буферов памяти, которые он совместно использует с MSSearch. CLR использует своего клерка для вызова сборщика "мусора", а буферный пул (Buffer Pool) понуждает своего клерка реагировать только на внешнее вытеснение памяти в VAS. (Кстати, почему?) Внешнее вытеснение памяти: RM и Buffer Pool В перспективе SQLOS, Buffer Pool - это программа распределения одиночных страниц и используемый экстенсивно менеджер памяти. О внешнем вытеснении памяти сообщает операционная система Windows. На это реагирует RM, рассылая соответствующие оповещения клеркам. После получения оповещения, BP ещё раз вычисляет целевое значение доступной памяти, и разрешенный для использования BP объём физической памяти. Имейте в виду, что целевое значение не может быть меньше, чем установленное через sp_configure в параметре конфигурации значение min server memory, и не может превышать max server memory. Если новое целевое значение меньше текущего, доступного буфера, BP будет сжиматься до тех пор, пока не исчезает внешнее вытеснение физической памяти. В течение этого процесса BP пробует проводить высвобождение, а в случае с AWE, возвращать свободную физическую память обратно операционной системе. Вспомним, что в случае с SQL Server 2000, работающем в AWE режиме, BP не реагирует на вытеснение физической памяти. Внутреннее вытеснение памяти: BP и Resource Monitor
Уменьшение объёма BP приводит к внутреннему вытеснению памяти. Это один из путей для
BP, чтобы процесс претерпел внутреннее вытеснение физической памяти. Какие же компоненты
BP оповещают о внутреннем вытеснении памяти? Да, Вы правильно решили, что именно SQLOS
предоставляет BP механизм, который включает соответствующий внутреннему вытеснению
памяти индикатор RM. Как Вы знаете, RM распознаёт сигнал индикатора и инициирует
оповещение, которое рассылается клеркам. У BP есть свой клерк, которому RM вернёт
это оповещение. Конечно же, тут не будет зацикливания!? На самом деле, всё обстоит
так потому, что BP занимается только контролем внешнего вытеснения физической памяти
и игнорирует любое внутреннее вытеснение физической. Вытеснение памяти VAS
До сих пор автор рассматривал то, как SQLOS, а следовательно и SQL Server, организует
вытеснение внешней и внутренней физической памяти. Обслуживание вытеснения VAS даётся
труднее, потому что Windows сложнее его распознать. О вытеснении VAS оповещение RM
может осуществляться по двум путям. Первый путь проходит через узел памяти, когда
виртуальные или разделяемые интерфейсы узла памяти не смогут распределять куски по 4
МБ и менее (RM не получит оповещение, если размер куска больше 4 МБ), после чего узел
памяти включает в RM индикатор недостаточности VAS. Тут же существует более активный
путь, когда при своей работе RM проверяет наличие в VAS блока в 4 МБ, и если такого
куска не находиться, он сам индицирует недостаточность VAS, и начинает рассылать
соответствующее оповещение. Контроль вытеснения памяти
Эта статья не будет полной без обзора возможностей контроля и диагностики разных типов
вытеснения памяти при работе SQL Server. Разработчики существенно облегчили для нас
эти возможности. Существует dm-представление, которое показывает хронологию вытеснения
памяти.
(имеется несколько разных закольцованных буферов, которые можно указать в условии выборки , включая: планировщики, исключения и "out of memory", но это уже темы для другой статьи) Вот пример возможного результата исполнения этого запроса:
Второй запрос показывает, когда BP, программа распределения одиночных страниц, инициирует/завершает внутреннее вытеснение памяти:
Если отсортировать результаты обоих запросов по времени, можно наблюдать реальное
поведение SQL Server в течение времени при вытеснении памяти. Заключение Вытеснение памяти может оказывать сильное воздействие на производительность сервера и стабильность его работы. Особенно это критично, когда SQL Server совместно использует сервер с другими приложениями или конкурирует за VAS с расширенными хранимыми процедурами или CLR. Вытеснение памяти может задействовать дополнительные ресурсы I/O, рекомпиляции и другие паразитные действия. Поэтому, понимание и диагностика разных типов вытеснения памяти, которым подвержен SQL Server, является очень важной частью управления сервером и разработки приложений баз данных. Автор надеется, что эта статья поможет Вам делать эту работу более эффективно. Сравнение SQL Server 2000 Index Tuning Wizard и SQL Server 2005 Database Tuning Adviser
По материалам статьи Luis Martin:
Comparing the SQL Server 2000 Index Tuning Wizard and the SQL Server 2005 Database Tuning Adviser
Среди повседневных задач DBA, есть одна, для которой все мы должны находить время, это
исследования. Автор проводит свои исследования с помощью новых инструментов, которые
упрощают эти задачи. Анализ с использованием SQL Server 2000 Index Tuning Wizard (ITW) Запрос, который анализировал автор, был таким:
Этот запрос, скопированный в Query Analyzer, имел следующий план исполнения:
Статистика выполнения запроса показала следующие значения:
После анализа этих результатов, автор запустил ITW, который представил следующие рекомендации по индексам:
Ожидаемое улучшение при использовании этих индексов составляло 52 %. После применения индексов, получился следующий плана исполнения:
А статистика данных после создания индексов выглядела так:
Как можно видеть, улучшения очевидны. Число логических чтений в таблице TRANSAC было сокращено с 31004 до 1889. Повторяем анализ, используя SQL Server 2005 Database Tuning Advisor (DTA) Далее, автор хотел посмотреть, как тот же самый запрос будет проанализирован в DTA. Сначала, автор удалил созданные ранее индексы, а затем анализировал те же самые запрос и данные, используя DTA. В этом случае, план исполнения выглядел так:
Статистика данных, соответствующая исполняемому запросу, была следующей:
Как видно, различия между статистиками запроса, исполняемого до оптимизации, минимальны, что и ожидалось. После этого, автор запустил DTA, и он предложил создать следующие ниже индексы, ожидая улучшения на 78 %.
Уже здесь мы наблюдаем некоторые различия. С одной стороны, процент улучшения у ITW
был 52 %, а у DTA - 78 %. С другой стороны, стоит обратить внимание на то, что
предложенные индексы имеют различия.
Статистика, полученная после выполнения запроса с новыми индексами, следующая:
Здесь, мы видим очень схожие цифры ITW и DTA для таблицы TRANSAC, но большие различия
статистики для таблицы CMPASOCIADOS. После перезапуск сервера, автор выполнил в Query Analyzer запрос, и получил следующую статистику:
Как можно видеть, статистика фактически та же самая, поэтому можно сделать заключение,
что предлагаемые DTA индексы лучше.
Заключение
Точно также, как ITW SQL Server 2000 лучше по сравнению с аналогом в SQL Server 7.0,
DTA SQL Server 2005 Beta 3 стал выдавать более качественные рекомендации, чем его
предшественник.
Data and Text Mining Tutorials Самые популярные темы недели
Ваше мнение об упражнениях SELECT на http://sql.ipps.ru
Кластер и слетевшие настройки |
Вопросы, предложения, коментарии, замечания, критику и т.п. оставляйте Виталию Степаненко и Александру Гладченко в форуме: Обсуждение рассылки
|
Subscribe.Ru
Поддержка подписчиков Другие рассылки этой тематики Другие рассылки этого автора |
Подписан адрес:
Код этой рассылки: comp.soft.winsoft.sqlhelpyouself |
Отписаться
Вспомнить пароль |
В избранное | ||