Базовый анализ проблем на сервере СУБД. Часть 1. Инфраструктурные проблемы

При получении жалоб от клиента, таких как «все тормозит», «пользователи жалуются», «процесс работает слишком медленно» и т. д. для диагностики проблемы «ДБ-сервис» проводит большое число проверок.

В этой статье мы расскажем о том, как мы помогаем в решении инфраструктурных проблем на сервере СУБД. К ним принято относить все, что связано с железом: CPU, RAM, дисковую подсистему и сеть.

Физическая перегруженность сервера может вести к возникновению ошибки соединения с сервером базы данных (Error establishing a database connection), поэтому, чтобы не ставить под угрозу бесперебойность вашего бизнеса, необходимо постоянно отслеживать, сколько ресурсов есть в распоряжении у вашего оборудования.

Среди базовых инструментов мониторинга можно назвать монитор активности СУБД, а также стандартные инструменты Windows, которые позволяют получать информацию в более развернутом варианте: диспетчер задач и монитор ресурсов. Рассмотрим подробнее каждый из них.

Этот инструмент помогает отслеживать ряд важных показателей, например потребление CPU и дисковой подсистемы, а также число выполняющихся пакетов и ждущих процессов.

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

Во вкладке «Процессы» можно легко найти корень блокировки, если вдруг исчезли все скрипты.

Что чаще всего тормозит процессы:

● Buffer I/O – очередь к буферу ввода-вывода, если показатели большие (например, выше 80), вероятно выполняется несколько запросов с неверными планами.
● Logging – очередь на запись в лог транзакций базы, если есть эта очередь, значит в базе идет очень много операций изменения или добавления данных (или же есть какие-то проблемы с диском под журналы транзакций).
● Lock – количество активных блокировок.

Диспетчер задач — известный инструмент Windows, который эффективно агрегирует информацию, например о чтении / записи на диски. Также в диспетчере можно посмотреть, сколько ресурсов потребляют те или иные пользователи и узнать подробности об используемом ими софте.

Монитор ресурсов можно открыть через тот же Диспетчер задач. В нем можно посмотреть более точную информацию о загрузке ядер или дисковых очередях. Больше всего стоит обращать внимание на разбивку по ядрам общей нагрузки CPU, а также время отклика (нормальным считается не более 10 мс.) и очереди на дисках (в норме — не более 20).

Также в Мониторе ресурсов можно подробно посмотреть на структуру использования памяти, хотя использование памяти СУБД и не всегда корректно отображается в цифрах.

Если время отклика составляет более 100 мс., а длина очереди — превышает 100, это свидетельствует о наличии проблем. Можно предположить, что дело в нехватке процессорных мощностей, однако, если график использования CPU не зашкаливает за 100%, нужно проверить в Диспетчере задач, как нагружено каждое из ядер. Если часть из них простаивает, то скорее всего они просто не используются СУБД (например, из-за ограничения лицензии).

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

Если рассматривать диск физически как одно устройство, то более двух запросов в очереди будут сигналить о том, что диск перегружен и не успевает обрабатывать поступающие запросы.

Однако мы почти всегда имеем дело с системами хранения данных, включающих десятки дисков в различных RAID-конфигурациях и некоторое количество быстрого SSD-кэша.

К примеру, для одиночного жесткого диска критическим считается значение больше 2, а если диск располагается на RAID-массиве из 4-х дисков, то волноваться стоит при значении больше 4*2=8.

Дисковые очереди более 100 являются нормой для мощных систем хранения данных на SSD-дисках в случае их активного использования, но в такие моменты диски с очередями будут выдавать скорости в тысячи Мбайт/с.

Как правило это сообщения в логах ОС и СУБД, которые можно быстро просмотреть процедурой xp_ReadErrorLog с панели администратора, и которые явно указывают на наличие неполадок.

Есть два основных способа посмотреть подробности аварии.

Вариант 1. Подключиться к инстансу, на котором возникла авария и посмотреть Extended Event.

Если это расширенное событие не отображается (при наличии сведений об аварии в «Zabbix» и логах сервера), значит, оно не влезла в лог событий Extended Event.

Чтобы исправить это, нужно кликнуть в SSMS по «error8623» правой кнопкой мыши, перейти по пути prorerties (свойства) ⇒ advanced (дополнительно) и увеличить размер max memory size. По дефолту там выставлено 4МБ (на некоторых серверах 8МБ), и не все события могут записаться. Для внесения изменений нужно остановить данную политику, а затем не забыть запустить ее заново.

Вариант 2. Посмотреть файл, расположение которого ищется следующим запросом:

В зависимости от версии директории могут меняться, но обычно речь идет о таких вариантах, как:

При появлении таких сообщений «ДБ-сервис» своевременно оповещает своих клиентов, указывая время и запрос, которые отображаются в логе.

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

Это сообщение говорит о нехватке процессорных ресурсов в конкретный момент времени. Вероятно на этот момент пришлась пиковая нагрузка на CPU (до 100%). Если в логе много таких сообщений, то это явное свидетельство перегруженности процессора.

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

Появление этого сообщения может косвенно свидетельствовать о нехватке оперативной памяти или о повышенной нагрузке на неё.

Кроме этого сообщения могут также появляться аналогичные сообщения со словом dump. Как правило они означают, что случился дамп СУБД (иногда с падением службы). Они могут также указывать на инфраструктурные проблемы — но это уточнить может только профессионал.

В заключение перечислим нормальные показатели сервера СУБД, на которые «ДБ-сервис» ориентируется в своей работе:

Отметим, что при больших показателях скоростей чтения / записи (более 300 Мбайт/с., а особенно более 1 Гбайт/с.) высокое значение очередей и большое время отклика считается условно нормальным - это особенности работы некоторых систем хранения данных.

Мы рассмотрели базовые инструменты для мониторинга производительности и диагностики инфраструктурных проблем на сервере СУБД. Были затронуты темы косвенных показателей наличия неполадок, основные виды ошибок, а также приведены нормальные показатели производительности сервера.

Обращение к нашим инженерам, специализирующимся на администрировании серверов СУБД — залог защиты ваших баз данных от любых ошибок подключения к серверу базы данных, вызванных перегрузками железа.