Как узнать сколько sql server занимает оперативной памяти

Обновлено: 04.07.2024

Анализ загрузки памяти средствами Системного монитора, счетчики Обмен страниц в сек (Pages/Sec), Buffer cache hit ratio (Процент попаданий в кэш буфера), Рабочее множество (Working Set), Ошибок страницы/сек (Page faults/sec), Доступно байт (Available baits), Total Server Memory (KB) (Общая память сервера (KB)), память AWE, параметр awe enabled

С точки зрения Microsoft , самая важная подсистема для баз данных OLTP (к которым относятся почти все используемые в повседневной работе базы данных) — это подсистема оперативной памяти. Более 90% запросов пользователей на чтение и запись обслуживается из буфера в оперативной памяти, без необходимости немедленного обращения к диску. Кроме того, нехватка памяти ведет к свопингу (активному обращению к файлу подкачки) и может привести к дополнительной нагрузке на процессорную и дисковую подсистемы.

Главный счетчик для анализа загрузки оперативной памяти с точки зрения операционной системы — это счетчик Обмен страниц в сек ( Pages/sec ) объекта Память ( Memory ). Физически этот счетчик показывает количество обращений в секунду к файлу подкачки (неважно, на чтение или запись). В курсах по SQL Server 6.5 и 7.0 пороговое значение этого счетчика определялось равным 5, в курсах по SQL Server 2000 — равным 10. В курсах и документации по SQL Server 2005 пороговое значение для этого счетчика вообще не определяется (пишут только о недопустимости его большого значения). Когда системе на самом деле не хватает оперативной памяти, значение этого счетчика измеряется сотнями, так что ошибиться здесь трудно. Отметим, что критична только информация, собранная за длительный промежуток времени — кратковременные скачки этого счетчика вполне допустимы.

Главный счетчик для определения того, хватает ли памяти самому SQL Server 2005, — счетчик Buffer cache hit ratio (Процент попаданий в кэш буфера) объекта Buffer Manager (Менеджер буфера) для данного экземпляра сервера. Он показывает, сколько запросов пользователей (в процентах к общему) обслуживаются из буфера без необходимости обращения к диску. Как уже говорилось ранее, рекомендуется, чтобы в течение длительного промежутка времени значение этого счетчика было не меньше 90%.

Для мониторинга подсистемы оперативной памяти можно использовать и другие счетчики:

q если вы подозреваете, что в расходе памяти виноват не SQL Server 2005, а другое приложение, имеет смысл обратиться к объекту Процесс и посмотреть на значения счетчиков Рабочее множество (Working Set) и Ошибок страницы/сек (Page faults/sec). Первый счетчик показывает, сколько памяти в настоящий момент использует каждый конкретный процесс, второй — сколько раз для этого процесса пришлось обращаться к файлу подкачки. Значения этих счетчиков для объекта процесса SQL Server нужно сравнить с экземпляром _Total и другими процессами;

q счетчик Доступно байт (Available baits) для объекта Память представляет объем физической памяти компьютера, которая свободна и может быть немедленно выделена какому-либо процессу. Значение этого счетчика в течение длительного промежутка времени не должно приближаться к 0;

q счетчик Total Server Memory (KB) (Общая память сервера ( KB )) для объекта Memory Manager (Менеджер памяти) соответствующего экземпляра SQL Server определяет, сколько именно виртуальной памяти (включая страницы в файле подкачки) используют подсистемы SQL Server . Это значение должно быть существенно ниже, чем объем физической оперативной памяти на сервере.

Если вы определили, что на сервере не хватает оперативной памяти, то естественно для решения проблемы ее нужно добавить. Однако отметим некоторые моменты, которые связаны с оперативной памятью для SQL Server 2005.

В 32-разрядных системах существуют ограничения на объем адресуемой оперативной памяти — 4 Гбайт. Если на сервере оперативной памяти больше (а такие системы все чаще встречаются на предприятиях), то для того, чтобы SQL Server мог использовать всю память, нужно предпринять необходимые действия и в операционной системе, и на самом SQL Server . В операционной системе нужно прописать для ее строки загрузки (пути ARC ) в файл boot.ini дополнительный параметр /PAE ( Physical Address Extension — расширение физических адресов), например:

multi(0)disk(0)risk(0)partition(2)\WINDOWS="Windows Server 2003, Enterprise RU" /no execute=opt out /fast detect /PAE

На SQL Server нужно включить параметр AWE enabled (Address Windowing Extensions). Включение его может выглядеть так :

sp_configure 'show advanced options', 1;

sp_configure 'awe enabled', 1;

После этого нужно перезапустить сервер.

Работа SQL Server в режиме AWE сопряжена с определенными проблемами. В частности, SQL Server никогда не отдает выделенную ему память AWE обратно, эта память никогда не выгружается в файл подкачки, могут возникнуть проблемы с распределением памяти AWE между экземплярами SQL Server , работающими на одном компьютере. Поэтому настоятельно рекомендуется при использовании режима AWE всегда устанавливать для SQL Server параметры min server memory (минимальное количество памяти, используемой SQL Server ) и max server memory (максимальное количество памяти), например, так:

sp_configure 'min server memory', 1024;

sp_configure 'max server memory', 6144;

Вообще, если ваша задача "доросла" то таких требований к ресурсам, имеет смысл подумать о приобретении 64-разрядного сервера. Конечно, работать с 64-разрядной версией SQL Server 2005 не очень удобно (например, из-за необходимости запускать некоторые средства администрирования только на 32-разрядной системе, т. е. удаленно), но 64-разрядная система действительно может обеспечить большой выигрыш в производительности. Кроме того, 64-разрядные системы могут работать с памятью практически неограниченного объема.

Отметим еще один момент, который связан с увеличением физического количества оперативной памяти. При принятии решения о добавлении на сервер физической оперативной памяти всегда нужно помнить еще про один параметр — кэш второго уровня ( L 2 cache ), который уже многие годы является компонентом процессора. Размер кэша второго уровня — это один из главных параметров, который отличает процессоры линейки Celeron от обычных Pentium и обычные Pentium — от серверных вариантов. Если кэша второго уровня недостаточно, то увеличение производительности при добавлении оперативной памяти будет происходить очень нелинейно, а в некоторых (совсем редких) случаях может и упасть. Оптимальный вариант — когда 2 Кбайт кэша второго уровня приходятся на каждый мегабайт физической оперативной памяти, хотя могут быть и другие варианты. В этом случае лучше посмотреть техническую документацию по серверной платформе — какой объем оперативной памяти для нее является рекомендуемым.

Перечень наиболее часто встречающихся проблем связанных с памятью:

SQL Server “съел” всю память (или очень много), что начало “угнетать” ОС и приложения работающие на ней.
Вы установили ограничения на память потребляемую SQL Server и ему стало не хватать выделенной памяти.
Какое-либо приложение потребило слишком много памяти и SQL Server-у стало не хватать выделенной памяти
“Перекос” в потреблении памяти каким-либо компонентом SQL Server, что стало причиной “угнетения” других компонентов SQL Server.

Первые три причины называются внешним “нажимом” на память и методика их анализа почти одинакова. Третья же причина называется “внутренним” нажимом на память и методики ее анализа совершенно другие.

Итак начнем рассмотрение первой причины – “SQL Server “съел” всю (или очень много) память, что начало угнетать ОС и приложения работающие на ней.”

В качестве ограничения накладываемого на рассмотрение – в блоге мы будем рассматривать только 64-битовую версию SQL Server и ОС, поскольку 32-битовых остается все меньше и меньше.

Для начала надо установить факт, что ОС действительно не хватает памяти и эту память потребил SQL Server. Выполнить это можно посмотрев счетчик Memory: Available Bytes. Он показывает сколько памяти осталось у ОС для распределения приложениям и внутреннего использования. Возникает справедливый вопрос:”Каким образом приложение может потребить много памяти и угнетать ОС?”. Причин тому может быть несколько:

Утечка памяти в приложении или драйвере, особенно утечка невыгружаемого пула.
Установка завышенного значения параметра “max server memory” в свойствах SQL Server и права “Lock Pages in Memory” для учетной записи от которой работает SQL Server.

У нас (Microsoft) есть принятая норма на остаток памяти который должен оставаться доступным для распределения ОС. Эта норма составляет 5% от объема установленного RAM, т.е. в свободном распределении у ОС должно остаться не менее 5% от общего объема RAM установленного на сервере. И как бы это число не казалось большим (особенно при больших объемах установленной памяти), лучше этого правила придерживаться.
Что будет предпринимать ОС, когда приложения потребят слишком много оперативной памяти? При достижении порога Memory: Available Bytes в 100…50 MB Windows включит агрессивный сброс (trimming) рабочих наборов процессов, включая системные драйверы, что тут же приведет к резкому снижению производительности всех компонентов ОС. В данной статье мы не будем рассматривать эти вопросы, возможно мы рассмотрим их в будущем.

Каким образом рассчитать правильное значение “max server memory”?

Здесь есть два случая:

Некластеризованный SQL Server, либо кластеризованный SQL Server в режиме Актив/Пассив .
Кластеризованный SQL Server работающий в режиме Актив/Актив.

Расчет памяти для некластеризованного, либо кластеризованного SQL Server работающего в режиме Актив/Пассив

Остаток для ОС – 5%. В нашем случае это около 25 GB (500*5%).
Память под ядро SQL Server (различные *.exe, *.dll, *ocx и пр. модули), SQL heap, CLR. Обычно это до 500 MB, хотя за счет CLR это может быть и больше.
Память под кэши “Worker thread”, рассчитываемая по формуле (512+(NumCpu-4)*16)*2 MB. В нашем случае это (512+(64-4)*16)* 2MB = 2944 MB (около 2.7 GB).
Итого под “max server memory” остается: 500 – 25 – 0.5 – 2.7 = 471.2 GB. Т.е. размер Буферного пула (при таком значении “max server memory”) может вырасти до 471 GB.
Для версии SQL 2012 и далее “max server memory” включает в себя SQL heap и частично CLR.

Особенно актуален это расчет, если вы используете “Lock Pages In Memory” В этом случае завысив это число или оставив его по умолчанию (что обозначает – любой объем) вы можете поставить ОС в довольно неприятное положения, которое приведет к агрессивному триммированию рабочих наборов и, как следствие, резкому замедлению работы системы.

При расчете необходимо учитывать, что пункты 2, 3 и 4 должны быть удвоены, и при использовании права учетной записи SQL Server “Lock Pages In Memory”, вам необходимо подобрать не только “max server memory”, но и “min server memory”, что бы в случае переката обоих SQL Server на один узел вы не забрали всю память у ОС.

В данном случае на сервере установлено 500 GB оперативной памяти и 5% должно быть около 25 GB. Каким бы большим не казалось это число, но чем больше на сервере процессоров и памяти, тем (как правило) более ресурсоемкие задачи он выполняет и для их решения ему требуются большие ресурсы.

Как видно из рисунка (в данном случае), остаток памяти на сервере составляет около 7 GB, что не соответствует нашим рекомендациям.

Далее нам необходимо понять, имеет ли SQL Server достаточный запас памяти, часть которого можно освободить в пользу ОС. Для ответа на этот вопрос необходимо проанализировать счетчики производительности SQL Server.

Давайте сначала выясним сколько памяти потребил SQL Server. Для этого надо знать, использует или нет SQL Server право учетной записи SQL Server “Lock Page In Memory”, Выяснить это можно из свойств учетной записи, а можно косвенно, через счетчики Performance Monitor. Дело в том, что если право учетной записи SQL Server “Lock Page In Memory” не установлено, то вся (или почти вся) используемая память будет частью рабочего набора процесса sqlservr.exe. Если же это право установлено, то при этом (скрыто) используется механизм AWE (Address Windows Extension) и основная память под Буферный пул будет размещена за пределами процесса sqlservr.exe.

Как видно из рисунка ниже, размер рабочего набора процесса составляет всего около 4 GB, что значительно меньше общего объема потребленной памяти.

Посмотрим, сколько всего памяти использует SQL Server. Он использует 500 857 024 (около 480 GB) для распределения на Буферный пул, Процедурный кэш, кэш Worker Thread и для некоторых не значительных потребителей. А отсюда можно сделать вывод, что в данном случае SQL Server использует “Lock Pages in Memory”.

Далее приступим к поиску ответа на вопрос:”Можно ли отобрать часть памяти у SQL Server, не нанося ему вреда?”

Во первых, давайте проверим какое количество запросов обслуживается из Буферного пула (без выполнения физических чтений). Как мы видим из рисунка ниже по тексту около 100% (точнее 99,972%) запросов выполняются из буферного пула (при пороговом значении данного счетчика не менее 92%), что дает нам надежду на наличие избытка памяти у SQL Server.

Следующим счетчиком, который рекомендуется посмотреть является SQL Server: Page Life Expectancy. Он контролирует время жизни страниц в Буферном пуле. Пороговое значение 300 секунд. В данном случае мы видим среднее значение около 221000, что почти в 700 раз больше порогового. Это укрепляет нас в мысли, что ресурсы есть.

Окончательный ответ нам поможет дать счетчик SQL Server: Lazy Writes/sec, отображающий как часто срабатывает процесс Lazy Writer. Мы знаем, что это процесс активируется тогда, когда у SQL Server заняты около 75% выделенных буферов. Его задача выполнить фиксацию данных и очистить буферы. Для систем имеющих значительный запас памяти этот счетчик должен быть близок к нулю. Как мы видим это так.

Из всего вышесказанного можно сделать вывод: SQL Server имеет достаточный объем памяти и может “поделиться” ей с ОС. Отбирая память у SQL Server (уменьшая “max server memory”) необходимо контролировать выше описанные счетчики и определить тот порог, ниже которого уменьшать объем памяти нельзя.

Проводите периодический мониторинг экземпляра SQL Server для подтверждения того, что память используется в допустимых пределах.

Настройка максимального размера памяти для SQL Server

По умолчанию экземпляр SQL Server может со временем использовать большую часть памяти, доступной операционной системе Windows на сервере. После занятия памяти она не высвобождается, пока не будет обнаружена нехватка памяти. Такое поведение является нормальным и не свидетельствует об утечке памяти в процессе SQL Server. Чтобы ограничить объем памяти, который сервер SQL Server может использовать в своих целях, задайте параметр max server memory. Дополнительные сведения см. в статье Руководство по архитектуре управления памятью.

В SQL Server на Linux установить ограничение памяти можно с помощью средства mssql-conf и параметра memory.memorylimitmb.

Наблюдение за памятью операционной системы

Для отслеживания нехватки памяти используйте приведенные ниже счетчики Windows. Значения многих счетчиков памяти операционной системы можно запрашивать с помощью динамических административных представлений sys.dm_os_process_memory и sys.dm_os_sys_memory.

Память: доступно байтов
Этот счетчик указывает на то, сколько байт памяти доступно на данный момент для использования процессами. Низкие значения счетчика Доступно байтов могут указывать на общую нехватку памяти операционной системы. Это значение можно запросить с помощью T-SQL из sys.dm_os_sys_memory.available_physical_memory_kb.

Память: ошибок страницы/с Этот счетчик показывает частоту ошибок страниц для всех процессов, включая системные. Низкий, но не нулевой уровень выгрузки на диск (и вызванные ею ошибки страниц) является нормальным, даже если у компьютера достаточно большое количество доступной памяти. Диспетчер виртуальной памяти (VMM) Microsoft Windows берет страницы из SQL Server и других процессов по мере того, как он урезает размеры рабочих множеств этих процессов. Деятельность VMM может привести к ошибкам страниц.

Процесс: ошибок страницы/с Этот счетчик показывает частоту ошибок страниц для определенного пользовательского процесса. С помощью счетчика Процесс: ошибок страниц/с можно определить, вызвана ли повышенная активность диска подкачкой, выполняемой сервером SQL Server. Чтобы определить, является ли SQL Server или другой процесс причиной излишней подкачки, наблюдайте за счетчиком Процесс: ошибок страниц/с для экземпляра процесса SQL Server.

Дополнительные сведения об устранении проблемы излишней подкачки см. в документации по операционной системе.

Изоляция памяти, используемой SQL Server

Для мониторинга использования памяти сервером SQL Server используйте приведенные ниже счетчики объектов SQL Server. Значения многих счетчиков объектов SQL Server можно запрашивать с помощью динамических административных представлений sys.dm_os_performance_counters и sys.dm_os_process_memory.

По умолчанию сервер SQL Server управляет требованиями к памяти динамически исходя из доступных ресурсов системы. Если SQL Server нужно больше памяти, он производит запрос к операционной системе, чтобы определить, доступна ли свободная физическая память, и использует ее. Если в операционной системе недостаточно свободной памяти, SQL Server будет освобождать память для операционной системы до тех пор, пока нехватка памяти не будет устранена или пока SQL Server не достигнет предела min server memory. Однако можно отказаться от динамического использования памяти, задав значения для параметров конфигурации сервера min server memory и max server memory. Дополнительные сведения см. в разделе Параметры памяти сервера.

Для мониторинга объема памяти, используемого SQL Server , наблюдайте за следующими счетчиками производительности.

SQL Server: Memory Manager: общая память сервера (КБ)
Этот счетчик показывает объем памяти операционной системы, выделенной в настоящее время серверу SQL Server диспетчером памяти SQL Server. Данное значение, как правило, увеличивается при повышении активности и растет после запуска SQL Server. Получить этот счетчик можно из столбца committed_kb динамического административного представления sys.dm_os_sys_info.

SQL Server: Memory Manager: память целевого сервера (КБ)
Этот счетчик показывает идеальный объем памяти для SQL Server в соответствии с рабочей нагрузкой за последнее время. Чтобы определить, выделен ли для сервера SQL Server оптимальный объем памяти, сравните это значение со счетчиком Общая память сервера по истечении некоторого периода работы со стандартной нагрузкой. Значения счетчиков Общая память сервера и Память целевого сервера должны быть примерно равны. Если значение Общая память сервера значительно меньше, чем значение Память целевого сервера, возможно, экземпляру SQL Server не хватает памяти. Через некоторое время после запуска SQL Server значение Общая память сервера возрастает. При этом значение Память целевого сервера должно быть больше, чем Общая память сервера. Получить этот счетчик можно из столбца committed_target_kb динамического административного представления sys.dm_os_sys_info. Дополнительные сведения и рекомендации по настройке памяти см. в статье Параметры конфигурации памяти сервера.

Процесс: рабочий набор
Этот счетчик показывает объем физической памяти, используемой процессом в настоящее время, согласно данным операционной системы. Обратите внимание на экземпляр этого счетчика для sqlservr.exe. Получить этот счетчик можно из столбца physical_memory_in_use_kb динамического административного представления sys.dm_os_process_memory.

Процесс: байт исключительного пользования
Этот счетчик показывает объем памяти операционной системы, запрошенный процессом для использования в собственных целях. Обратите внимание на экземпляр этого счетчика для sqlservr.exe. Так как этот счетчик учитывает все выделения памяти, запрошенные процессом sqlservr.exe, включая выходящие за пределы max server memory, его значение может превышать значение параметра max server memory.

SQL Server: Buffer Manager: страниц базы данных
Этот счетчик указывает число страниц с содержимым базы данных в буферном пуле. Память, не относящаяся к буферному пулу процесса SQL Server, не учитывается. Запросить этот счетчик можно из динамического административного представления sys.dm_os_performance_counters.

SQL Server: Buffer Manager: коэффициент попаданий в буферный кэш
Этот счетчик относится только к SQL Server. Желательно, чтобы коэффициент был не меньше 90. Значение выше 90 указывает на то, что более 90 процентов всех запрошенных данных были получены из кэша данных в памяти без считывания с диска. Дополнительные сведения о диспетчере буферов SQL Server см. в статье SQL Server, объект Buffer Manager. Запросить этот счетчик можно из динамического административного представления sys.dm_os_performance_counters.

SQL Server: Buffer Manager: ожидаемое время существования страницы
Этот счетчик измеряет, сколько секунд самая старая страница находится в буферном пуле. Для систем с архитектурой NUMA это среднее значение для всех узлов NUMA. Чем больше это значение, тем лучше. Его резкое падение указывает на постоянное обновление данных в буферном пуле, из-за которого рабочая нагрузка недостаточно эффективно использует данные, уже находящиеся в памяти. У каждого узла NUMA имеется собственный узел буферного пула. На серверах с несколькими узлами NUMA узнать ожидаемое время существования страницы для каждого узла буферного пула можно с помощью счетчика SQL Server: узел буфера: ожидаемое время существования страницы. Запросить этот счетчик можно из динамического административного представления sys.dm_os_performance_counters.

Примеры

Определение текущего распределения памяти

Приведенные ниже запросы возвращают сведения о текущем распределении памяти.

Определение текущего объема памяти, используемого сервером SQL Server

Приведенный ниже запрос возвращает сведения о текущем использовании памяти сервером SQL Server.

Довольно часто пользователи, разработчики и администраторы СУБД MS SQL Server сталкиваются с проблемами производительности БД или СУБД в целом, поэтому весьма актуальным является мониторинг MS SQL Server.

Данная статья является дополнением к статье Использование Zabbix для слежения за базой данных MS SQL Server и в ней будут разобраны некоторые аспекты мониторинга MS SQL Server, в частности: как быстро определить, каких ресурсов не хватает, а также рекомендации по настройке флагов трассировки.

Для работы следующих приведенных скриптов, необходимо создать схему inf в нужной базе данных следующим образом:

Метод выявления нехватки оперативной памяти

Первым показателем нехватки оперативной памяти является тот случай, когда экземпляр MS SQL Server съедает всю выделенную ему ОЗУ.

Для этого создадим следующее представление inf.vRAM:

Тогда определить то, что экземпляр MS SQL Server потребляет всю выделенную ему память можно следующим запросом:

Если показатель SQL_server_physical_memory_in_use_Mb постоянно не меньше SQL_server_committed_target_Mb, то необходимо проверить статистику ожиданий.

Для определения нехватки оперативной памяти через статистику ожиданий создадим представление inf.vWaits:

В этом случае определить нехватку оперативной памяти можно следующим запросом:

Здесь нужно обратить внимание на показатели Percentage и AvgWait_S. Если они существенны по своей совокупности, то есть очень большая вероятность того, что оперативной памяти не хватает экземпляру MS SQL Server. Существенные значения определяются индивидуально для каждой системы. Однако, можно начинать со следующего показателя: Percentage>=1 и AvgWait_S>=0.005.

Для вывода показателей в систему мониторинга (например, Zabbix) можно создать следующие два запроса:

Метод выявления чрезмерной нагрузки на ЦПУ

Для выявления нехватки процессорного времени достаточно воспользоваться системным представлением sys.dm_os_schedulers. Здесь, если показатель runnable_tasks_count постоянно больше 1, то существует большая вероятность того, что количество ядер не хватает экземпляру MS SQL Server.

Для вывода показателя в систему мониторинга (например, Zabbix) можно создать следующий запрос:

Исходя из динамики полученных значений по данному показателю, можно сделать вывод достаточно ли процессорного времени (количества ядер ЦПУ) для экземпляра MS SQL Server.
Однако, важно помнить о том факте, что сами запросы могут запрашивать сразу несколько потоков. И порой оптимизатор не может верно оценить сложность самого запроса. Тогда запросу могут быть выделено слишком много потоков, которые в данный момент времени не могут быть обработаны одновременно. И это тоже вызывает тип ожидания, связанный с нехваткой процессорного времени, и разрастания очереди на планировщики, которые используют конкретные ядра ЦПУ, т е показатель runnable_tasks_count в таких условиях будет расти.

В таком случае перед тем как увеличивать количество ядер ЦПУ, необходимо правильно настроить свойства параллелизма самого экземпляра MS SQL Server, а с 2016 версии-правильно настроить свойства параллелизма нужных баз данных:

Здесь стоит обратить внимания на следующие параметры:

Max Degree of Parallelism-задает максимальное количество потоков, которые могут быть выделены каждому запросу (по умолчанию стоит 0-ограничение только самой операционной системой и редакцией MS SQL Server)
Cost Threshold for Parallelism-оценочная стоимость параллелизма (по умолчанию стоит 5)
Max DOP-задает максимальное количество потоков, которые могут быть выделены каждому запросу на уровне базы данных (но не более, чем значение свойства «Max Degree of Parallelism») (по умолчанию стоит 0-ограничение только самой операционной системой и редакцией MS SQL Server, а также ограничение по свойству «Max Degree of Parallelism» всего экземпляра MS SQL Server)

По собственному опыту рекомендую следующий алгоритм действий для OLTP-систем для настройки свойств параллелизма:

сначала запретить параллелизм, выставив на уровне всего экземпляра Max Degree of Parallelism в 1
проанализировать самые тяжелые запросы и подобрать для них оптимальное количество потоков
выставить Max Degree of Parallelism в подобранное оптимальное количество потоков, полученное из п.2, а также для конкретных баз данных выставить Max DOP значение, полученное из п.2 для каждой базы данных
проанализировать самые тяжелые запросы и выявить негативный эффект от многопоточности. Если он есть, то повышать Cost Threshold for Parallelism.
Для таких систем как 1С, Microsoft CRM и Microsoft NAV в большинстве случаев подойдет запрет многопоточности

Для OLAP-систем описанный выше алгоритм не подходит.

По собственному опыту рекомендую следующий алгоритм действий для OLAP-систем для настройки свойств параллелизма:

проанализировать самые тяжелые запросы и подобрать для них оптимальное количество потоков
выставить Max Degree of Parallelism в подобранное оптимальное количество потоков, полученное из п.1, а также для конкретных баз данных выставить Max DOP значение, полученное из п.1 для каждой базы данных
проанализировать самые тяжелые запросы и выявить негативный эффект от ограничения параллелизма. Если он есть, то либо понижать значение Cost Threshold for Parallelism, либо повторить шаги 1-2 данного алгоритма

Итоги

В данной статье были разобраны некоторые аспекты мониторинга MS SQL Server, с помощью которых можно оперативно выявить нехватку ОЗУ и свободного времени ЦПУ, а также ряд других менее очевидных проблем. Были рассмотрены наиболее часто используемые флаги трассировки.

Читайте также: