Основы мониторинга производительности и диагностики проблем в SQL Server

В этой статье мы рассмотрим популярные инструменты, T-SQL запросы и скрипты для обнаружения и решения различных возможных проблем с производительностью SQL Server. Эта статья поможет вам разобраться, когда вашему SQL Server недостаточно ресурсов (памяти, CPU, IOPs дисков), найти блокировки, выявить медленные запросы. Посмотрим какие есть встроенные инструменты и бесплатные сторонние скрипты и утилиты для анализа состояния Microsoft SQL Server.

Инструменты для диагностики SQL Server

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

• T-SQL — самый мощный, простой и незаменимый инструмент для поиска проблем и анализом производительности SQL Server. Практически все другие инструменты для работы с SQL Server используют T-SQL. Нет ничего такого, чтобы вы не смогли сделать с помощью T-SQL.
• SQL Server Management Studio — без SSMS практически невозможно работать с SQL Server. С помощью SSMS вы можете посмотреть Activity monitor, проанализировать план запроса, посмотреть параметры сервера или базы данных и многие другие вещи.
• Журналы ошибок SQL Server и Windows – если что-то идёт не так, журнал ошибок — это первое место, куда смотрит системный администратор. Журнал ошибок SQL Server можно посмотреть через SSMS. Журналы Windows можно посмотреть через оснастку eventvwr.msc.
• Монитор ресурсов Windows — resmon.exe незаменимый инструмент Windows для быстрой оценки состояния ресурсов сервера. Использование оперативной памяти и процессора можно посмотреть и через Диспетчер задач, но детальное использование сети и жесткого диска можно посмотреть только через resmon и perfmon.
• Системный монитор Windows (Performance Monitor) — Perfmon.exe это основное средство мониторинга Windows, он содержит в себе разнообразные “счетчики”, как системных метрик, так и приложений, включая SQL Server. Обычно счетчики perfmon обрабатывают с помощью других систем мониторинга, например, Zabbix , так как в perfmon неудобно хранить и смотреть данные за прошедшее время.
• Сторонние приложения — существует много платных и бесплатных приложений для мониторинга SQL Server. Например, одним из бесплатных приложений является dbForge Monitor от компании Devart. Приложение устанавливается как дополнение к SSMS и позволяет выводить очень удобный дашборд для отображения текущего состояния вашего SQL Server (информация об использовании памяти, CPU, нагрузках, блокировках, процессах, информацию о бэкапах, “тяжелых SQL запросах”, производительности дисковой подсистемы и т.д.).
• Скрипты Brentozar – это популярное решение для диагностики настроек и работоспособности SQL Server. У brentozar есть много скриптов для различных задач, но для диагностики нас интересует “sp_blitz”. Скачать можно бесплатно с официального сайта https://www.brentozar.com/blitz/ . Запустите sp_Blitz.sql чтобы установить необходимые процедуры и выполните их exec sp_blitz для диагностики. Этот инструмент бесплатный и поддерживается сообществом SQL Server. Sp_blitz определит все популярные проблемы с вашим сервером и посоветует как их решить.
• Наборы T-SQL скриптов — удобно иметь под рукой коллекции разнообразных T-SQL запросов для диагностики SQL Server, так как не всегда есть время писать собственные запросы, лучше вооружиться заранее. Ниже перечислены ссылки на полезные T-SQL/PowerShell запросы, которые я часто использую при диагностике и тюнинге MS SQL:
  • https://github.com/SQLadmin/AwesomeSQLServer — набор запросов для мониторинга CPU/RAM/Disk IO и прочих параметров.
  • https://github.com/dgavrikov/databases_scripts/tree/master/SQL%20Server – много полезных скриптов и лайфхаков
  • https://github.com/ktaranov/sqlserver-kit — Скрипты и полезная информация. Много примеров работы с SQL Server через PowerShell

Обнаружение и решение проблем с производительностью SQL Server

Самой распространенной проблемой с которой сталкивается системный администратор, работающий с SQL Server, это жалобы пользователей на производительность запросов и самого сервера: “тормозит”, “долго выполняется запрос“, и так далее.

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

Анализ использования оперативной памяти SQL Server

Для начала нужно определить сколько памяти доступно SQL Server. Для этого запустите SSMS (SQL Server Management Studio), зайдите на сервер и зайдите в свойства сервера (ПКМ по названию сервера в Обозревателе объектов).

Сам по себе доступный объём RAM вам ничего не скажет. Нужно сравнить это число с используемой памятью в Диспетчере Задач и самим движком SQL Server с помощью DMV.

В Диспетчере задач, во вкладке Подробности, найдите sqlservr.exe и посмотрите сколько оперативной памяти использует этот процесс.

• Если на сервере, например, 128 GB оперативной памяти, а процесс sqlservr.exe использует 60 GB и ограничений по RAM у SQL Server нет, то оперативной памяти вам хватает.
• Если SQL Server использует 80-90% RAM от заданной или максимальной, то в таком случае нужно смотреть DMV. Имейте в виду, что sqlservr.exe не сможет использовать всю оперативную память. Если на сервере 128 GB, то sqlservr.exe может использовать только 80-90% (100-110 GB), так как остальная память резервируется для операционной системы.

Имейте в виду, что процесс SQL Server’a не отдаёт оперативную память обратно в систему. Например, ваш SQL Server обычно использует 20 GB памяти, но при месячном отчете он увеличивает потребление до 100 GB, и даже когда вычисление отчета закончится и сервер будет работать в прежнем режиме, процесс SQL Server’a всё равно будет использовать 100 GB до перезагрузки службы.

Даже если вы уверены, что оперативной памяти серверу хватает, не будет лишним точно знать объём потребляемой RAM.

Узнать реальное использование RAM можно с помощью Dynamic Management Views . DMV это административные вьюверы (представления). С помощью DMV можно диагностировать практически любую проблему в SQL Server.

Посмотрим sys.dm_os_sys_memory, для удобства используем запрос:

SELECT total_physical_memory_kb / 1024 AS_x000D__x000D_[Total Physical Memory],_x000D__x000D_available_physical_memory_kb / 1024 AS_x000D__x000D_[Available Physical Memory],_x000D__x000D_total_page_file_kb / 1024 AS_x000D__x000D_[Total Page File (MB)],_x000D__x000D_available_page_file_kb / 1024 AS_x000D__x000D_[Available Page File (MB)],_x000D__x000D_100 - ( 100 * Cast(available_physical_memory_kb AS DECIMAL(18, 3)) / Cast_x000D__x000D_(_x000D__x000D_ total_physical_memory_kb AS DECIMAL(18, 3)) ) AS_x000D__x000D_'Percentage Used',_x000D__x000D_system_memory_state_desc AS_x000D__x000D_[Memory State]_x000D__x000D_FROM sys.dm_os_sys_memory;_x000D_

Рассмотрим каждый выводимый параметр:

1. [ Total Physical Memory ] – объём оперативной памяти доступный в операционной системе. На некоторых серверах может показывать немного больше реально установленной.
2. [ Available Physical Memory ] – объём оперативной памяти доступный для SQL Server, без учета уже захваченной SQL Server.
3. [ Total Page File (MB)] – Объём “Сommit limit”. Commit Limit = Оперативная память + все файлы подкачки. То есть, если у вас на сервере 32 GB оперативной памяти и 16 GB файл подкачки, commit limit будет 48 GB.
4. [ Available Page File (MB) ] – Объём файла подкачки.
5. Percentage Used – процент занятой оперативной памяти. Такого параметра нет в самом sys.dm_os_sys_memory, но он считается по формуле available_physical_memory_kb / total_physical_memory_kb
6. [ Memory State ] – Состояние RAM. Поле system_memory_state_desc содержит в себе состояние потребления оперативной памяти в виде текста. Значение этого поля считается исходя из других двух: system_low_memory_signal_state и system_high_memory_signal_state. Вы можете выбирать их напрямую, если вам нужен Boolean/bit формат данных. Для ознакомления со всеми полями sys.dm_os_sys_memory ознакомьтесь с документацией https://docs.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-os-sys-memory-transact-sql?view=sql-server-ver15

Все эти данные полезны, если вы хотите точно определить сколько ваш SQL Server потребляет RAM. Чаще всего это используют, если есть подозрения что для экземпляра выделено слишком много оперативной памяти.

Если Вам нужно убедиться, что серверу хватает RAM, вы можете смотреть только на поля system_low_memory_signal_state, system_high_memory_signal_state и system_memory_state_desc. Если system_low_memory_signal_state = 1, то серверу явно не хватает оперативной памяти.

Загрузка процессора в SQL Server

Нагрузку на процессор определить проще, так как это можно сделать в Диспетчере задач. Чтобы узнать текущую нагрузку на процессор, найдите в Диспетчере задач процесс sqlservr.exe

Если вы хотите узнать нагрузку за прошедшее время, можно воспользоваться запросом:

DECLARE @ts BIGINT;_x000D__x000D_DECLARE @lastNmin TINYINT;_x000D__x000D_SET @lastNmin = 30;_x000D__x000D_SELECT @ts = (SELECT cpu_ticks / ( cpu_ticks / ms_ticks )_x000D__x000D_FROM sys.dm_os_sys_info);_x000D__x000D_SELECT TOP(@lastNmin) Dateadd(ms, -1 * ( @ts - [timestamp] ), Getdate())AS_x000D__x000D_[EventTime],_x000D__x000D_sqlprocessutilization AS_x000D__x000D_[SQL Server Utilization],_x000D__x000D_100 - systemidle - sqlprocessutilization AS_x000D__x000D_[Other Process CPU_Utilization],_x000D__x000D_systemidle AS_x000D__x000D_[System Idle]_x000D__x000D_FROM (SELECT_x000D__x000D_record.value('(./Record/@id)[1]', 'int') AS record_id,_x000D__x000D_record.value('(./Record/SchedulerMonitorEvent/SystemHealth/SystemIdle)[1]', 'int') AS [SystemIdle],_x000D__x000D_record.value('(./Record/SchedulerMonitorEvent/SystemHealth/ProcessUtilization)[1]', 'int')AS [SQLProcessUtilization],_x000D__x000D_[timestamp]_x000D__x000D_FROM (SELECT[timestamp],_x000D__x000D_CONVERT(XML, record) AS [record]_x000D__x000D_FROM sys.dm_os_ring_buffers_x000D__x000D_WHERE ring_buffer_type = N'RING_BUFFER_SCHEDULER_MONITOR'_x000D__x000D_AND record LIKE'%%')AS x)AS y_x000D__x000D_ORDER BY record_id DESC;

В результате мы получим поминутную статистику использования процессора.

Анализ нагрузки на диск SQL Server

Посмотрим на загрузку дисков в операционной системе. Для этого запустите resmon.exe.

Нам нужна вкладка Disk . В секции Disk Activity отображаются файлы, к которым идёт обращение, и их скорость read/write на текущий момент. Отфильтруйте эту секцию по Total (кликните на Total). На самом верху будут файлы, которые на данный момент максимально используют диск. В случае с SQL Server это может быть полезно чтобы определить какая база больше всего нагружает диск на текущий момент.

В секции Storage отображаются все диски в системе. В этой секции нам нужны 2 параметра – Active Time и Disk Queue. Active Time в процентах отображает нагрузку на диск, то есть если вы видите на диске C: Active Time равный 90, это значит что ресурс чтения/записи диска на текущий момент используется на 90%. Столбец Disk Queue отображает очередь обращений к диску, и если значение очереди не равно нулю, то диск загружен на 100% и не справляется с нагрузкой. Так же если Active Time близок к 100, то диск используется практически на пределе своих возможностей по скорости.

Просмотр блокировок в SQL Server

После того как мы убедились, что серверу хватает ресурсов, можно переходить к просмотру блокировок.

Блокировки можно посмотреть через Activity Monitor в SSMS, но мы воспользуемся T-SQL, так как этот вариант более удобен и нагляден. Выполняем запрос:

SET NOCOUNT ON_x000D_GO_x000D_SELECT SPID, BLOCKED, REPLACE (REPLACE (T.TEXT, CHAR(10), ' '), CHAR (13), ' ' ) AS BATCH_x000D_INTO #T_x000D_FROM sys.sysprocesses R CROSS APPLY sys.dm_exec_sql_text(R.SQL_HANDLE) T_x000D_GO_x000D_WITH_x000D_BLOCKERS (SPID, BLOCKED, LEVEL, BATCH)_x000D_AS_x000D_(_x000D_SELECT SPID,_x000D_BLOCKED,_x000D_CAST (REPLICATE ('0', 4-LEN (CAST (SPID AS VARCHAR))) + CAST (SPID AS VARCHAR) AS VARCHAR (1000)) AS LEVEL,_x000D_BATCH_x000D_FROM #T R_x000D_WHERE (BLOCKED = 0 OR BLOCKED = SPID)_x000D_AND EXISTS (SELECT *_x000D_FROM #T R2_x000D_WHERE R2.BLOCKED = R.SPID AND R2.BLOCKED <> R2.SPID)_x000D_UNION ALL_x000D_SELECT R.SPID,_x000D_R.BLOCKED,_x000D_CAST (BLOCKERS.LEVEL + RIGHT (CAST ((1000 + R.SPID) AS VARCHAR (100)), 4) AS VARCHAR (1000)) AS LEVEL,_x000D_R.BATCH_x000D_FROM #T AS R_x000D_INNER JOIN BLOCKERS ON R.BLOCKED = BLOCKERS.SPID_x000D_WHERE R.BLOCKED > 0 AND R.BLOCKED <> R.SPID_x000D_)_x000D_SELECT N' ' + REPLICATE (N'| ', LEN (LEVEL)/4 - 1) +_x000D_CASE WHEN (LEN(LEVEL)/4 - 1) = 0_x000D_THEN 'HEAD - '_x000D_ELSE '|------ ' END_x000D_+ CAST (SPID AS NVARCHAR (10)) + N' ' + BATCH AS BLOCKING_TREE_x000D_FROM BLOCKERS_x000D_ORDER BY LEVEL ASC_x000D_GO_x000D_DROP TABLE #T_x000D_GO_x000D_

Этот запрос возвращает список блокировок в виде дерева. Это удобно в работе, так как обычно, если возникает одна блокировка, она провоцирует за собой другие. Аналогично в Activity Monitor или в выводе sp_who2 можно увидеть поле “Blocked By”.

Если запрос ничего не вернул, то блокировок нет.

Если запрос вернул какие-то данные, то нужно проанализировать цепочку.

HEAD значит что этот запрос является причиной всех остальных блокировок ниже по дереву. 64 – это идентификатор процесса (SPID). После этого пишется тело запроса, который вызвал блокировку. Если у вас хватает ресурсов сервера, то скорее всего дело в самом запросе и во взаимном обращении к каким-то объектам. Для того чтобы сказать точнее, нужно анализировать конкретный запрос, который вызвал блокировку.

Политики SQL Server

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

Политика в SQL Server это, грубо говоря, проверка правила на соответствие заданному значению. Например, с помощью политик вы можете убедиться, что на всех базах на сервере выключен Auto Shrink. Рассмотрим пример импорта и выполнения политики

В SSMS, подключитесь к серверу, на котором хотите выполнять политики (Management -> раздел Policy Management).

Импортируем файл Database Auto Shrink.xml. Жмём Evaluate

На экземпляре node1 две базы данных, test1 и test2. На test2 включен autoshrink. Посмотрим детали.

Политика определила включенный параметр AutoShrink, в описании обычно пишется объяснения к правилам. В данном случае дается объяснение почему auto shrink лучше отключать.

Политики могут выполняться либо по расписанию, либо по требованию (разово). Результаты выполнения политики можно посмотреть в журнале политик.

При установке SQL Server нужно выбирать только используемые компоненты СУБД, и указывать настройки в соответствии с конфигурацией “железа” вашего сервера. Всегда следите чтобы серверу хватало ресурсов, и чтобы на сервере не было блокировок

Самым мощным инструментом для диагностики SQL Server является T-SQL и DMV. Так же рекомендуется построить круглосуточный мониторинг над SQL Server и над обслуживающей его инфраструктурой для обнаружения всех возможных проблем.