PG_HAZEL + IOSTAT : Определение причин инцидента производительности СУБД

ℹ️Работы по проекту "PG_HAZEL"-завершены.Исследования продолжены в проекте PG_EXPECTOℹ️

Сила - в кооперации усилий !

Анализ причин инцидента

Наибольшая корреляция между ожиданиями СУБД и типом ожиданий IO.

ALARM: более 50% наблюдений - Отклик на запись свыше 5мс

Вопрос

Какое событие является первичным - рост ожиданий чтения/записи в метрике iostat(проблемы устройства) или рост ожиданий типа IO в СУБД PostgreSQL ?

Ответ

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

Короткий ответ: Первичным почти всегда является рост ожиданий чтения/записи в iostat (проблемы на уровне устройства). Рост ожиданий ввода-вывода (I/O wait) в PostgreSQL — это уже следствие этой проблемы.

Детальное объяснение

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

1. iostat и ожидания устройства (await, svctm)

• Что это такое? Утилита iostat показывает метрики непосредственно от операционной системы, которая общается с устройством хранения (HDD, SSD, RAID-массив, SAN).

Ключевые метрики:

• await (или r_await/w_await) — Среднее время, которое требуется для обслуживания одного запроса ввода-вывода (в миллисекундах). В это время входит не только само время обслуживания запроса (svctm), но и время, проведенное в очереди.
• svctm — Среднее время обслуживания одного запроса самим устройством (миллисекунды). Это "чистая" скорость работы диска.
• %util — Процент загруженности устройства. Показывает, какую часть времени устройство было занято обработкой запросов.

Что означает рост?

Если await растет (например, с 5 мс до 100 мс), это означает, что устройство физически не успевает обрабатывать поступающие запросы. Запросы начинают скапливаться в очередь.

Причины:

• Слишком высокая нагрузка (много одновременных запросов).
• Проблемы с самим устройством (медленный HDD, деградация SSD, проблемы с RAID-массивом).
• Конкуренция за ресурсы со стороны других процессов (например, резервное копирование, другое приложение).

Вывод на этом уровне:

Устройство стало медленным.

ОС и все процессы, которые пытаются что-то прочитать или записать, вынуждены ждать его ответа.

2. Ожидания ввода-вывода в PostgreSQL

Что это такое?

В PostgreSQL (и других СУБД) существуют счетчики ожиданий (wait events). Они показывают, на чем "спит" каждый backend-процесс, ожидая какой-либо ресурс.

Ключевые ожидания, связанные с I/O:

• DataFileRead — Ожидание чтения данных из файла таблицы.
• DataFileWrite — Ожидание записи данных в файл таблицы.
• WALWrite — Ожидание записи в журнал предзаписи (Write-Ahead Log).
• CheckpointWrite — Ожидание во время записи данных контрольной точки.

Что означает рост?

Если в pg_stat_activity или в отчетах мониторинга - высокий процент времени, проведенного процессами в состояниях DataFileRead/DataFileWrite, это означает, что процессы СУБД простаивают, ожидая, когда ОС и диск выполнят их запросы.

Вывод на этом уровне

PostgreSQL хочет работать, но не может, потому что подсистема ввода-вывода не отвечает вовремя.

Он фиксирует это ожидание как симптом.

Цепочка событий (Как это происходит на практике)

1. Начинается проблема на диске: По какой-либо причине (возросла нагрузка, начались проблемы с железом) физическое устройство хранения начинает отвечать медленнее.
2. ️ Фиксируется в iostat: Медленные отклики устройства сразу видны в iostat — растут показатели await, svctm, может расти очередь (avgqu-sz).
3. Замедляется ОС: Процесс ядра ОС, отвечающий за I/O, не может быстро обработать системные вызовы (read, write) от всех программ, включая PostgreSQL.
4. Замедляется PostgreSQL: Процессы СУБД, которые сделали системный вызов для чтения страницы данных или записи WAL, блокируются и переходят в состояние ожидания. В pg_stat_activity появляются сессии с wait_event_type = 'IO'.
5. Проявляется для пользователя: Запросы начинают выполняться дольше, растет время отклика приложения, могут появляться таймауты.

Исключения и важные замечания

Не всегда виноват диск

Иногда причиной высокого await в iostat является не само устройство, а то, как его использует PostgreSQL.

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

Первична все равно проблема на уровне ОС (iostat покажет высокий await), но корень ее — в неправильной работе приложения.

Диагностика

Правильный путь диагностики — идти от симптома к причине:

1. Вы видите, что запросы в БД стали медленными.
2. Смотрите pg_stat_activity — много IO wait.
3. Немедленно смотрите iostat (например, iostat -x 1), чтобы подтвердить проблему на уровне устройства.

• Если iostat показывает проблему, вы ищете ее причину: нагрузка, железо, конкуренция за ресурсы.
• Если iostat показывает, что диск почти простаивает (await низкий, %util низкий), а в PostgreSQL при этом высокие ожидания I/O — это очень странная ситуация, которая может указывать на проблемы с файловой системой, драйверами или даже баг в самой СУБД.

Итог

1. Рост ожиданий в iostat — это первичное событие, которое является причиной.
2. Рост ожиданий I/O в PostgreSQL — это вторичное событие, которое является следствием.

Мониторинг ОС (включая iostat, vmstat, top) всегда должен быть первым пунктом для проверки при любых подозрениях на проблемы с производительностью БД.