Задача
Проанализировать влияние проблем производительности инфраструктуры на снижение производительности СУБД .
Производительность и ожидания СУБД
Анализ показателей инфраструктуры (iostat)
Анализ метрики w-await
С какими событиями ожидания (wait_event) может коррелировать рост значений w_await (iostat) для СУБД PostgreSQL ?
Рост показателя w_await в iostat (среднее время ожидания завершения операций записи на диск) в контексте PostgreSQL обычно коррелирует с событиями ожидания типа IO (Input/Output), которые указывают на то, что процессы СУБД активно ждут завершения операций записи на диск.
DataFileWrite
Ожидание записи данных в файл основной таблицы или индекса.
Высокая нагрузка UPDATE/INSERT, недостаточно быстрая работа подсистемы хранения.
WALWrite / WALWrite
Ожидание записи в журнал предзаписи (Write-Ahead Log, WAL).
Интенсивные изменения данных (любые DML-операции), синхронная репликация, настройки synchronous_commit
BufFileWrite
Ожидание записи во временный файл на диске.
Объемные операции, не помещающиеся в work_mem (сортировки, хэш-соединения), большие запросы с CREATE TEMPORARY TABLE.
SLRUWrite
Ожидание записи данных в структуры SLRU (например, журналы транзакций clog).
Очень высокая интенсивность commit/rollback транзакций.
DSMFillZeroWrite
Ожидание инициализации (заполнения нулями) нового сегмента динамической разделяемой памяти.
Активное использование параллельных запросов.
События ожиданий типа IO
80% ожиданий типа IO вызваны событиями ожиданий DataFileRead и DSMFillZeroWrite
- DataFileRead Ожидание чтения из файла данных отношения.
- DSMFillZeroWrite Ожидание заполнения нулями файла, применяемого для поддержки динамической общей памяти.
Статистика ожиданий типа IO на уровне SQL запросов для операций записи на диск
Итог
Рост времени ожидания записи(w_await/iostat) на дисковых устройствах используемых СУБД оказывает существенное влияние на рост ожиданий типа IO и снижение производительности СУБД.
Последствия и возможные причины роста значений w_await выше 11ms:
🔴 Критические проблемы инфраструктуры
1. Перегрузка подсистемы хранения
- Нехватка IOPS: Диски не справляются с количеством операций записи в секунду
- Исчерпание пропускной способности: Превышение лимитов по MB/s на уровне хранилища
- Высокая задержка (latency) контроллера: Проблемы с HBA-адаптерами или контроллерами RAID
2. Проблемы с конфигурацией хранилища
- Неправильный RAID уровень: RAID-5/6 для write-intensive workload (типично для PostgreSQL)
- Отсутствие BBU/конденсаторов: Нет кэширования записи на контроллере
- Неоптимальный размер stripe: Слишком маленький или большой stripe size
3. Конкуренция за ресурсы
- "Шумные соседи": Другие ВМ/контейнеры на том же гипервизоре активно пишут
- Совместное использование дисков: WAL, данные и TEMP на одних дисках
- Фоновые процессы: Бэкапы, vacuum, аналитика на той же системе
4. Проблемы сетевого хранилища (SAN/NAS)
- Сетевая задержка: Проблемы с сетью 10GbE/FC
- Перегруженные порты коммутатора
- Проблемы на стороне массива хранения
📊 Интерпретация значений w_await
Значение w_await : 1-5 ms
Серьезность: ✅ Норма
Возможные причины: SSD, хорошо настроенное хранилище
Значение w_await : 5-10 ms
Серьезность: ⚠️ Внимание
Возможные причины: Начальная стадия перегрузки
Значение w_await : 10-20 ms
Серьезность: 🔶 Проблема
Возможные причины: Явные проблемы с IOPS/пропускной способностью
Значение w_await : 20-50 ms
Серьезность: 🔴 Критично
Возможные причины: Серьезная перегрузка хранилища
Значение w_await : 50+ ms
Серьезность: 🚨 Авария
Возможные причины: Практически отказ хранилища
📈 Когда бить тревогу?
- Постоянные значения > 20 ms - требуется срочное вмешательство
- Пики > 50 ms во время checkpoint - необходимо оптимизировать контрольные точки
- Рост w_await вместе с количеством active sessions - масштабирование необходимо
Значение 11 ms - это уже явный сигнал, что подсистема хранения работает на пределе и требует оптимизации, особенно для высоконагруженной PostgreSQL.