Общая информация
Периоды наблюдения:
· Тестовый период: 2026-04-10 11:20 – 2026-04-10 12:20 (далее — Период 1)
· Инцидентный период: 2026-04-10 12:20 – 2026-04-10 13:20 (далее — Период 2)
Конфигурация СУБД:
· PostgreSQL 15.14, ОС AstraLinuxSE, виртуализация KVM
· CPU: 16 vCPU (Intel Xeon Skylake)
· RAM: 62.80 ГБ
· shared_buffers = 16079 МБ
· effective_cache_size = 48237 МБ
· maintenance_work_mem = 1024 МБ
· work_mem = 12 МБ
· autovacuum_max_workers = 8, autovacuum_naptime = 1 с
· checkpoint_timeout = 15 мин, max_wal_size = 8 ГБ, min_wal_size = 2 ГБ
· random_page_cost = 1.1, effective_io_concurrency = 300
· Дисковые устройства: vdb (данные, /data), vdc (WAL, /wal)
Методология анализа: трёхэтапный анализ ожиданий (p-value, ВКО, R²), двухэтапный анализ корреляций метрик (p-value, R²), CPI — индекс приоритета корреляции.
1. Общий анализ операционной скорости и ожиданий СУБД
Граничные значения операционной скорости (SPEED) и ожиданий СУБД (WAITINGS)
Период 1 (тестовый):
· SPEED: MIN = 475128, MEDIAN = 987493, MAX = 1258560
· WAITINGS: MIN = 1590, MEDIAN = 2089, MAX = 3244
Период 2 (инцидентный):
· SPEED: MIN = 63999, MEDIAN = 241876, MAX = 652229
· WAITINGS: MIN = 1589, MEDIAN = 2088, MAX = 2826
Сравнение:
· Медианное значение SPEED снизилось с ~987 тыс. до ~242 тыс. (падение в 4,1 раза).
· Медианное значение WAITINGS практически не изменилось (2089 → 2088).
· Минимальное значение SPEED во втором периоде резко упало (475128 → 63999).
· Максимальное значение WAITINGS во втором периоде снизилось (3244 → 2826).
Примечание: WAITINGS представлены в виде суммарного счётчика ожиданий всех типов за интервал (вероятно, за минуту). SPEED = сумма запросов и обработанных строк.
Анализ трендов операционной скорости (SPEED) и ожиданий СУБД (WAITINGS)
Период 1:
· Тренд SPEED: R² = 0.290 (слабая модель), угол наклона = -28.28 (слабое падение). Модель объясняет менее 40% вариации, предсказательная способность низкая.
· Тренд WAITINGS: R² = 0.390 (слабая модель), угол наклона = +32.02 (рост). Модель слабая.
Период 2:
· Тренд SPEED: R² = 0.850 (очень высокая модель), угол наклона = -42.65 (устойчивое падение). Модель объясняет более 80% дисперсии, предсказательная способность высокая.
· Тренд WAITINGS: R² = 0.780 (хорошая модель), угол наклона = +41.37 (устойчивый рост). Модель достоверна.
Интерпретация:
· В период инцидента (Период 2) операционная скорость демонстрирует устойчивое и предсказуемое снижение, одновременно ожидания растут с высокой степенью объяснимости. Это свидетельствует о наличии стабильного негативного фактора, воздействующего на производительность.
Корреляция SPEED и WAITINGS:
· Период 1: r = -0.0642, незначима (p > 0.05), R² ≈ 0. Связь отсутствует.
· Период 2: r = -0.7822, значима (p < 0.05), R² = 0.610 (хорошая модель). Сильная обратная связь: рост ожиданий сопровождается падением операционной скорости.
1.1. СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД
Оба периода:
· Тип ожидания IO доминирует (WAITINGS ≈ сумма ожиданий IO, незначительные вкрапления LWLOCK).
· Для IO: корреляция с общими ожиданиями r = 1.000 (математическая зависимость, так как IO составляет почти 100% всех ожиданий).
· ВКО для IO = 1.000 (критическое значение).
· R² регрессии WAITINGS по IO = 1.000 (очень высокая модель).
Вывод: Ожидания практически полностью обусловлены вводом-выводом. Данный вывод тривиален, так как IO составляет ~100% WAITINGS. Дополнительной информации не несёт.
LWLOCK:
· Период 1: r = 0.7062, значима, но ВКО ≈ 0.000 (<0.01) — игнорируется.
· Период 2: r = 0.5977, значима, ВКО ≈ 0.000 — игнорируется.
Интегральный приоритет IO в обоих периодах = 0.6204.
Итог по разделу "1. СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД"
· Основной и единственный значимый тип ожиданий — IO.
· В период инцидента фиксируется устойчивый рост IO-ожиданий и устойчивое падение операционной скорости с сильной обратной корреляцией.
· Тестовый период не показывал значимой связи SPEED и WAITINGS.
1.2. ТРЕНДОВЫЙ АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ vmstat
Период 1:
· procs/r: медиана = 3 (при 16 ядрах), тренд с R²=0.58 (удовл.), положительный наклон, сильный тренд ухудшения.
· procs/b: медиана = 0, тренд отсутствует (R²=0).
· cpu/wa: медиана = 3%, тренд с R²=0.61 (хорошая), положительный наклон, сильный тренд ухудшения.
· cpu/id: медиана = 85%, тренд с R²=0.89 (очень высокая), отрицательный наклон, очень высокая скорость снижения — признак серьёзной проблемы.
Период 2:
· procs/r: медиана = 2, тренд с R²=0.41 (удовл.), отрицательный наклон, шум (улучшение).
· procs/b: медиана = 0, тренд с R²=0.53 (удовл.), положительный наклон, умеренный тренд ухудшения.
· cpu/wa: медиана = 2%, тренд с R²=0.20 (слабый), положительный наклон, шум.
· cpu/id: медиана = 88%, тренд с R²=0.37 (слабый), положительный наклон, шум.
Сравнение:
· В период инцидента тренды простоя CPU и ожидания IO потеряли предсказательную силу (R² снизился), хотя абсолютные значения wa и id остались на сходном уровне.
· В тестовый период фиксировался сильный негативный тренд по cpu/id и cpu/wa, что могло быть предвестником инцидента.
· В инцидентный период негативный тренд по procs/b стал умеренным, что указывает на рост процессов в uninterruptible sleep.
Итог по разделу "2. ТРЕНДОВЫЙ АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ vmstat"
· Тестовый период характеризовался выраженным ухудшением показателей CPU idle и ожиданий IO.
· В инцидентный период эти тренды ослабли, но операционная скорость СУБД резко упала, что может указывать на смещение узкого места внутрь СУБД или изменение характера нагрузки.
1.3. СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД и МЕТРИК vmstat
Период 1:
· Значимые корреляции IO с bi (r=0.763, R²=0.58), bo (r=0.794, R²=0.63), wa (r=0.602, R²=0.36).
· Высокие корреляции cs с sy (r=0.970, R²=0.94), cs с us (r=0.866, R²=0.75), cs с in (r=0.928, R²=0.86).
Период 2:
· Корреляция IO с bi сохранилась (r=0.759, R²=0.58), с bo — стала незначима (отрицательная или отсутствует), с wa — r=0.630, R²=0.40 (удовл.).
· Корреляция cs с sy осталась очень высокой (r=0.896, R²=0.80), с us — r=0.785, R²=0.62, с in — стала слабой (r=0.404, модель непригодна).
Сравнение:
· Связь IO с записью (bo) исчезла во второй период, что указывает на изменение профиля нагрузки: доминирование чтения.
· Сильная связь cs с sy в обоих периодах указывает на высокие накладные расходы ядра на переключение контекста.
Относительные показатели vmstat:
· В обоих периодах свободная RAM менее 5% в 100% времени (ALARM). При общем объёме RAM 62.8 ГБ и shared_buffers=16 ГБ, effective_cache_size=48 ГБ, свободная память минимальна (около 1.1 ГБ). Система работает в условиях полного использования памяти под кэш страниц.
· Свопинг не используется.
· Очередь процессов run queue не превышала число ядер.
· sy < 30%, wa < 10%.
Итог по разделу "3. СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД и МЕТРИК vmstat"
· Основной драйвер ожиданий — операции чтения с диска (bi). Во втором периоде запись перестала коррелировать с IO, что может означать снижение активности контрольных точек или bgwriter.
· Низкая свободная память — хроническое состояние, но без свопинга. Требуется анализ hit ratio (нет данных).
· Высокие значения cs и sy указывают на возможную конкуренцию за CPU в ядре из-за частых системных вызовов.
1.4. ДИАГРАММЫ ПАРЕТО ПО WAIT_EVENT_TYPE и QUERYID
Период 1:
· IO: BufFileRead = 53.87%, DataFileRead = 46.05%.
· queryid 8811732978066195686: 1915 вызовов, 236314 ожиданий (98.07% от всех IO-ожиданий), события: BufFileWrite, DataFilePrefetch, DataFileExtend, DataFileRead, BufFileRead.
Период 2:
· IO: DataFileRead = 99.86%.
· queryid 8811732978066195686: 793 вызова, 164394 ожиданий (95.55% от IO-ожиданий), события: DataFilePrefetch, DataFileExtend, DataFileRead.
Сравнение:
· Во второй период резко сократилось количество вызовов проблемного запроса (с 1915 до 793), но доля его ожиданий осталась доминирующей.
· Исчезли BufFileRead/BufFileWrite, что может свидетельствовать об изменении плана выполнения или объёма данных, исключившего использование временных файлов.
· Абсолютное число ожиданий IO снизилось (с ~240k до ~172k), но операционная скорость упала сильнее, что говорит о снижении производительности запросов.
Итог по разделу "4. ДИАГРАММЫ ПАРЕТО ПО WAIT_EVENT_TYPE и QUERYID"
· Единственный значимый запрос (queryid 8811732978066195686) вызывает подавляющую часть IO-ожиданий в обоих периодах.
· Во второй период характер ожиданий сместился в сторону DataFileRead (чтение табличных файлов), временные файлы не используются.
Детальный анализ – граничные значения и корреляции
Ожидания СУБД
· IO является единственным значимым типом ожиданий (ВКО=1.0).
· Во второй период зафиксирована сильная обратная корреляция между SPEED и WAITINGS (r=-0.78), отсутствовавшая в первом периоде.
Память и буферный кэш
· memory_free: медиана ~1.1 ГБ (<2% от RAM) в обоих периодах.
· memory_cache: медиана ~54.3 ГБ, близка к effective_cache_size (48 ГБ) + shared_buffers (16 ГБ), но без данных о hit ratio невозможно оценить эффективность кэширования.
· memory_buff: стабилен (46–54 МБ), незначителен.
· Отсутствуют метрики pg_stat_database: blks_hit, blks_read, что не позволяет рассчитать cache hit ratio.
Недостаточно данных для выводов о достаточности shared_buffers и эффективности кэша. Требуются: blks_hit, blks_read за периоды.
Дисковая подсистема (I/O)
Анализ устройств vdb (данные) и vdc (WAL) по iostat представлен в разделе 2.
CPU и системные вызовы
· cpu_us + cpu_sy не превышали 80%, sy не превышало 30%.
· Высокая корреляция cs с sy (r~0.90-0.97) указывает на значительные затраты CPU в режиме ядра на переключение контекста, что может быть следствием большого числа системных вызовов (например, частые операции I/O или блокировки).
· Во второй период корреляция cs с in ослабла, что может говорить об изменении источника прерываний.
Блокировки и ожидания LWLock
· LWLock ожидания присутствуют, но их ВКО <0.01, следовательно, они не оказывают значимого влияния на общую производительность.
· Lock ожидания отсутствуют (COUNT=0).
Анализ запросов (queryid)
· Запрос 8811732978066195686 доминирует по IO-ожиданиям.
· Отсутствует текст запроса, план выполнения, статистика по чтениям/возврату строк. Без этой информации невозможно определить причину высокого IO.
Недостаточно данных: текст запроса, EXPLAIN (ANALYZE, BUFFERS), pg_stat_statements (calls, total_time, rows, shared_blks_read, local_blks_read, temp_blks_read).
2. Анализ IO
Список дисковых устройств
· vdb: 2 ТБ, LVM на /data (данные)
· vdc: 100 ГБ, LVM на /wal (WAL)
· vdd: 20 ГБ, LVM на /log (логи)
· vde, vdf: бэкапы (в анализе не участвуют)
Граничные значения по дисковым устройствам
Устройство vdb (данные):
· Период 1: util медиана 36.0% (MAX 53.49%), r_await медиана 1.02 мс, w_await 3.78 мс, aqu_sz медиана 2.04 (MAX 3.40).
· Период 2: util медиана 29.17% (MAX 49.43%), r_await медиана 1.01 мс, w_await 3.86 мс, aqu_sz медиана 1.76 (MAX 2.28).
Устройство vdc (WAL):
· Период 1: util медиана 5.07%, только запись (w/s ~15-25), w_await <1 мс.
· Период 2: util медиана 4.27%, аналогично.
Относительные показатели iostat
vdb:
· Период 1: %util>50% — 13.1% времени; aqu_sz>1 — 83.6% времени (ALARM).
· Период 2: %util>50% — 0%; aqu_sz>1 — 100% времени (ALARM).
· r_await и w_await <5 мс в 100% времени.
vdc:
· Все показатели в норме.
Интерпретация:
· Устройство vdb постоянно работает с глубиной очереди более 1, что указывает на наличие очереди запросов, но время отклика остаётся низким. Это характерно для высокопроизводительного хранилища (SSD), способного параллельно обрабатывать запросы.
· Во второй период нагрузка на vdb снизилась по %util, но очередь осталась стабильно >1.
2.1. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ "КОРРЕЛЯЦИЯ VMSTAT и IOSTAT" по дисковым устройствам
2.1.1 КОРРЕЛЯЦИЯ VMSTAT и IOSTAT
vdb:
· Период 1: wa ↔ util: r=0.796, R²=0.63 (хорошая). Ожидание CPU ввода-вывода сильно связано с загрузкой устройства.
· Период 2: wa ↔ util: r=0.856, R²=0.73 (хорошая). Связь сохранилась.
vdc:
· Период 1: wa ↔ util: r=0.500, R²=0.25 (слабая).
· Период 2: wa ↔ util: r=0.339, модель непригодна.
Вывод: Основной вклад в ожидания IO вносит устройство данных vdb.
2.1.2 БУФЕРИЗАЦИЯ ВВОДА-ВЫВОДА
vdb и vdc:
· Корреляции buff с rps, rMBps, wps, wMBps незначимы в обоих периодах.
· Буферный кэш файловой системы не демонстрирует связи с нагрузкой на диски.
2.1.3 КЭШИРОВАНИЕ ВВОДА-ВЫВОДА
vdb:
· Период 1: cache не коррелирует с показателями диска.
· Период 2: cache ↔ rMBps: r=0.901, R²=0.81 (очень высокая). Рост скорости чтения (МБ/с) сопровождается ростом объёма page cache.
Интерпретация: Во второй период интенсивное чтение данных приводит к увеличению использования page cache, что может указывать на последовательное сканирование больших объёмов данных, которые затем кэшируются. Это согласуется с доминированием DataFileRead.
2.1.4 КОРРЕЛЯЦИЯ ОПЕРАЦИОННОЙ СКОРОСТИ И МЕТРИК ПРОИЗВОДИТЕЛЬНОСТИ ДИСКОВОГО УСТРОЙСТВА
vdb:
· Период 1: SPEED ↔ IOPS: r=-0.710, R²=0.50 (удовл.). SPEED ↔ MBps: незначима.
· Период 2: SPEED ↔ IOPS: незначима. SPEED ↔ MBps: r=0.894, R²=0.80 (очень высокая).
Смена характера связи:
· В тестовый период рост количества операций ввода-вывода (IOPS) был связан со снижением операционной скорости (типично для random I/O).
· В инцидентный период операционная скорость стала сильно положительно коррелировать с пропускной способностью (МБ/с), что характерно для последовательного чтения больших объёмов.
ИНДЕКС ПРИОРИТЕТА КОРРЕЛЯЦИИ (CPI) для vdb
Период 1:
· wa ↔ util: CPI=0.794
· SPEED ↔ IOPS: CPI=0.000 (невалидно)
Период 2:
· cache ↔ rMBps: CPI=0.900
· SPEED ↔ MBps: CPI=0.844
· wa ↔ util: CPI=0.000 (невалидно)
Итог по разделу "СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ "КОРРЕЛЯЦИЯ VMSTAT и IOSTAT" по дисковым устройствам"
· Устройство vdb является основным источником IO-нагрузки.
· Во второй период произошло изменение профиля ввода-вывода: нагрузка сместилась от IOPS-ориентированной (случайное чтение/запись) к пропускной способности (последовательное чтение).
· Глубина очереди постоянно превышает 1, что указывает на насыщение очереди запросов, но время отклика остаётся низким, что характерно для современного SSD-хранилища.
· Рост cache при увеличении rMBps во второй период указывает на активное кэширование прочитанных данных.
Проблемы инфраструктуры по итогам сравнительного анализа
· Хронически низкая свободная память (<5%) без свопинга — потенциальный риск при пиковых нагрузках.
· Высокая глубина очереди на устройстве vdb в 83-100% времени — признак постоянной очереди ввода-вывода, что может приводить к увеличению задержек при дальнейшем росте нагрузки.
· Высокие затраты CPU в режиме system time на переключение контекста (корреляция cs с sy) — указывает на возможную неоптимальность приложения или конфигурации СУБД (например, слишком частые системные вызовы).
3. Итог
3.1 Ключевые проблемы
· Резкое падение операционной скорости (в 4 раза по медиане) в период инцидента при незначительном изменении абсолютных значений ожиданий.
· Устойчивый негативный тренд операционной скорости с высокой предсказательной способностью (R²=0.85) во втором периоде.
· Изменение профиля ввода-вывода с IOPS-ориентированного на throughput-ориентированный (последовательное чтение).
· Доминирование одного запроса (queryid 8811732978066195686) в создании IO-ожиданий.
3.2 Проблемы СУБД
· Ожидания IO являются единственным значимым типом ожиданий, что указывает на диск как на основное узкое место, но во втором периоде связь операционной скорости с пропускной способностью стала положительной, что нетипично для узкого места на диске (обычно рост чтения снижает скорость). Это может означать, что снижение скорости вызвано не диском, а конкуренцией за другие ресурсы (CPU, блокировки), а чтение является следствием, а не причиной.
· Отсутствие данных о hit ratio, планах запросов, pg_stat_statements ограничивает анализ.
3.3 Проблемы инфраструктуры
· Постоянная очередь на устройстве данных (aqu_sz >1), но с низкими задержками — пока не является прямым узким местом, но может стать им при росте нагрузки.
· Низкая свободная память — риск подкачки при пиках.
· Высокие значения system time и переключений контекста могут указывать на избыточные системные вызовы.
4. Общие рекомендации по оптимизации производительности СУБД и инфраструктуры
(Без конкретных предложений изменений конфигурации, только направления диагностики)
4.1 Конкретные рекомендации по оптимизации производительности СУБД
· Провести детальный анализ запроса queryid 8811732978066195686: получить текст, план выполнения с EXPLAIN (ANALYZE, BUFFERS, TIMING). Определить, почему во втором периоде изменился характер ожиданий (исчезли BufFileRead) и почему скорость упала.
· Проверить статистику pg_stat_statements для этого запроса: среднее время выполнения, количество возвращаемых строк, количество чтений shared_blks_read, local_blks_read, temp_blks_read.
· Оценить hit ratio (blks_hit / (blks_hit + blks_read)) для баз данных за оба периода. При значении ниже 95% — проанализировать возможность увеличения shared_buffers или оптимизации запросов.
· Проверить эффективность autovacuum: количество dead tuples, частоту vacuum. Возможно, рост чтений связан с просмотром большого числа устаревших версий строк.
4.2 Конкретные рекомендации по оптимизации инфраструктуры
· Мониторить глубину очереди и задержки на vdb при увеличении нагрузки. При росте r_await/w_await выше 10 мс рассмотреть распределение нагрузки или увеличение effective_io_concurrency.
· Проанализировать причины высокого system time и переключений контекста: возможно, приложение выполняет множество мелких транзакций или запросов. Рекомендуется профилирование на уровне ОС (perf, strace) для выявления частых системных вызовов.
· Увеличить объём доступной памяти для page cache (но параметр effective_cache_size уже близок к общему объёму RAM). Без свопинга текущее состояние памяти приемлемо, но требует наблюдения.
5. Заключение
· В период инцидента операционная скорость СУБД упала в 4 раза по медиане при сохранении абсолютного уровня ожиданий IO.
· Характер нагрузки на диск изменился: доминирует последовательное чтение больших объёмов данных одним запросом.
· Связь операционной скорости с пропускной способностью стала сильной положительной, что указывает на то, что падение скорости не вызвано напрямую диском, а, вероятно, ограничено CPU или блокировками.
· Для точной диагностики недостаточно данных: текст и план проблемного запроса, hit ratio, pg_stat_statements, распределение времени выполнения запросов.
· Инфраструктура демонстрирует стабильную работу дисковой подсистемы с низкими задержками, но высокая глубина очереди требует внимания при росте нагрузки.
Недостаточно данных для окончательных выводов. Для полного анализа необходимы:
· Данные pg_stat_database: blks_hit, blks_read, tup_returned, tup_fetched.
· Данные pg_stat_statements по queryid 8811732978066195686 (calls, total_time, rows, shared_blks_read, local_blks_read, temp_blks_read).
· План выполнения запроса (EXPLAIN (ANALYZE, BUFFERS)).
· Статистика по таблицам и индексам, участвующим в запросе (pg_stat_user_tables, pg_stat_user_indexes).
· Логи PostgreSQL за указанные периоды (для выявления возможных ошибок или предупреждений).