Общая информация
· Объект анализа: СУБД PostgreSQL 15.13 (конфигурация из файла _1.settings.txt) и инфраструктура (vmstat).
· Периоды сравнения:
o Инцидент: 2026-03-11 15:35 — 16:35 (файл _2.postgresql_vmstat.txt). Период, квалифицированный как инцидент производительности.
o Тест: 2026-03-11 14:35 — 15:35 (файл _2.1.test.postgresql_vmstat.txt). Период, взятый как тестовый отрезок для сравнения.
· Аппаратная конфигурация:
o CPU: 192 ядра (Intel Xeon Platinum 8280L), 4 NUMA-узла.
o RAM: ~1008 GB.
o Дисковая подсистема: Тома LVM на отдельных дисках для данных (/data, 56T), WAL (/wal, 1T), резервных копий (/backup, 2.9T) и логов (/log, 100G).
Общий анализ операционной скорости и ожиданий СУБД
Сравнительный анализ граничных значений операционной скорости (SPEED) и ожиданий СУБД (WAITINGS)
· Операционная скорость (SPEED):
o Инцидент: Медианная скорость (~11.78 млн) незначительно ниже, чем в тестовый период (~11.90 млн). Однако разброс значений (MIN-MAX) в инциденте шире, что указывает на нестабильность.
o Тест: Скорость более стабильна, с более высокими минимальными и медианными значениями.
· Суммарные ожидания (WAITINGS):
o Инцидент: Медиана ожиданий (~318.8 млн) немного ниже, чем в тесте (~326.9 млн). Это неочевидный момент: скорость падает, хотя суммарные ожидания чуть ниже. Это указывает на то, что критична не столько общая сумма, сколько структура ожиданий.
o Тест: Суммарные ожидания выше, но они менее "вредоносны" для пропускной способности.
Сравнительный анализ трендов операционной скорости (SPEED) и ожиданий СУБД (WAITINGS)
· Тренд SPEED (скорости):
o Инцидент (R²=0.94): Сильный отрицательный тренд (-44.09). Скорость неуклонно падает на протяжении часа, что является главным признаком деградации.
o Тест (R²=0.64): Небольшой положительный тренд (+38.68). Система работала стабильно или даже немного ускорялась.
· Тренд WAITINGS (ожиданий):
o Инцидент (R²=0.58): Умеренный положительный тренд (+37.28). Сумма ожиданий растет вместе с падением скорости.
o Тест (R²=0.07): Тренд отсутствует. Модель непригодна для прогноза, ожидания были стабильны.
· Регрессия SPEED от WAITINGS:
o Инцидент (R²=0.59): Модель показывает умеренную обратную связь (-37.64). Рост ожиданий объясняет падение скорости.
o Тест (R²=0.30): Связь есть, но модель слабая. Влияние ожиданий на скорость было менее прямым и фатальным.
1. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД
· BufferPin:
o Оба периода: Отсутствуют.
· Extension:
o Инцидент (ВКО=0.14, R²=0.66): Высокое влияние. Корреляция с общими ожиданиями значимая (0.81), что указывает на проблемы в работе расширений.
o Тест (ВКО=0.27, R²=0.99): Критическое влияние. Расширения были основным драйвером ожиданий. В инциденте их "вес" снизился, уступив место другим факторам.
· IO:
o Инцидент (ВКО=0.08, R²=0.65): Среднее влияние. Модель качественная, но вклад в общее время ожиданий не самый высокий.
o Тест (ВКО): Невалидно (отрицательная корреляция). В тестовом периоде IO-ожидания не были значимым фактором.
· IPC:
o Оба периода: Отсутствуют или незначимы.
· Lock:
o Инцидент (ВКО=0.08, R²=0.65): Среднее влияние, аналогично IO.
o Тест (ВКО): Невалидно.
· LWLock:
o Инцидент (ВКО=0.30, R²=0.55): Критическое влияние. Основной драйвер проблем. Модель R²=0.55 указывает на то, что LWLock объясняет большую часть вариации общих ожиданий.
o Тест (ВКО=0.27, R²=0.99): Критическое влияние. LWLocks также были важны, но в тесте они шли "в связке" с Extension и не вызывали падения скорости.
· Timeout:
o Оба периода: Отсутствуют.
Итог по разделу "1. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД"
· Ключевое изменение: Основная нагрузка сместилась с Extension в тестовом периоде на LWLock в инциденте. Хотя Extension все еще имеют высокий приоритет, их вклад в общее время ожиданий снизился, в то время как вклад LWLocks остался критически высоким.
· В инциденте также появились и стали значимыми ожидания типов IO и Lock, которые в тестовом периоде не оказывали влияния. Это говорит о том, что система вошла в фазу комплексной деградации, затронувшей диск и блокировки транзакций.
2. СРАВНИТЕЛЬНЫЙ ТРЕНДОВЫЙ АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ vmstat
· procs -> r (Очередь на CPU):
o Инцидент (R²=0.22): Слабый, негативный тренд (рост очереди). Модель бесполезна для прогноза, но тенденция к ухудшению есть.
o Тест (R²=0.84): Очень сильный позитивный тренд (очередь снижалась). Система "расхламлялась".
· procs -> b (Ожидание IO):
o Инцидент (R²=0.33): Слабый позитивный тренд (улучшение). Ситуация с процессами, заблокированными по IO, немного выправилась.
o Тест (R²=0.71): Сильный негативный тренд (рост). В тесте количество процессов, ждущих IO, росло, но это не привело к падению скорости, что говорит об эффективной асинхронной работе.
· cpu -> wa (Ожидание IO CPU):
o Инцидент (R²=0.28): Слабый позитивный тренд (улучшение).
o Тест (R²=0.00): Тренд отсутствует.
· cpu -> id (Простой CPU):
o Инцидент (R²=0.79): Сильный, катастрофический негативный тренд (-41.71). Процессорное время простоя стремительно сокращается. CPU начинает активно работать, но это не приводит к росту скорости СУБД (она падает). Это классический признак того, что CPU тратит время на бесполезную работу (оверхеды, ожидания).
o Тест (R²=0.28): Слабый позитивный тренд. CPU простаивал больше, что хорошо.
Итог по разделу "2. СРАВНИТЕЛЬНЫЙ ТРЕНДОВЫЙ АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ vmstat"
· Главный сигнал инцидента: Резкое падение cpu_id (простоя CPU) при одновременном падении скорости БД. CPU начинает активно работать, но не на выполнении полезной нагрузки, а на обслуживании простоев (скорее всего, связанных с LWLocks и конкуренцией).
· В тестовом периоде CPU простаивал больше, очереди на выполнение (r) сокращались — система была сбалансирована.
· Проблемы с диском (b, wa), наблюдавшиеся в тесте, в инциденте пошли на спад, что подтверждает смещение фокуса проблемы с IO на CPU и блокировки.
3. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД и МЕТРИК vmstat
· Extension:
o Инцидент: Очень сильная корреляция с us (user time) (0.91, R²=0.82) и сильная с in (прерывания) (0.83, R²=0.68). Это указывает на то, что расширения выполняют полезную работу на пользовательском уровне и генерируют прерывания (вероятно, сетевое или межпроцессное взаимодействие).
o Тест: Сильная корреляция только с us (0.65, R²=0.43). Связь с прерываниями была незначима. Это может означать, что характер работы расширений изменился: в инциденте они стали чаще взаимодействовать с внешней средой.
· LWLock, IO:
o Оба периода: Не продемонстрировали значимых корреляций с метриками vmstat. Это ожидаемо, так как LWLocks — это внутренняя конкуренция за память, а IO-метрики vmstat могут быть нивелированы кэшированием.
· Lock:
o Оба периода: Корреляция с r (очередь на CPU) значимая, но разного качества.
o Инцидент (R²=0.33): Слабая модель. Блокировки есть, они создают очередь, но это не главная причина роста r.
o Тест (R²=0.70): Качественная модель. Рост блокировок напрямую и сильно влиял на рост очереди процессов на CPU. Это подтверждает, что в тесте механизмы работали предсказуемо.
Итог по разделу "3. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД и МЕТРИК vmstat"
· Основное различие в поведении Extension. В инциденте они стали значительно сильнее коррелировать с прерываниями (in), что может указывать на изменение их паттерна работы (например, увеличение частоты вызовов внешних API или обмен по сети).
· Модель зависимости блокировок (Lock) от очереди на CPU (r) в инциденте стала слабой, хотя связь осталась. Это значит, что в формирование очереди на CPU теперь вносят вклад и другие факторы, прежде всего LWLocks, которые не отслеживаются напрямую vmstat.
4. СРАВНЕНИЕ ДИАГРАММ ПАРЕТО ПО WAIT_EVENT_TYPE и QUERYID
· Типы событий (Wait Event Type):
o Инцидент:
§ Extension: 100% (основной тип).
§ LWLock: Распределение изменилось. Главные события — BufferMapping (30.1%), WALWrite (26.1%), pgpro_stats (18.2%).
§ IO: Доминирует DataFileRead (78.3%), появились заметные ожидания WALSync (11.0%).
§ Lock: Основные события — transactionid (79.0%) и tuple (20.4%).
o Тест:
§ Extension: 100%.
§ LWLock: Схожий набор, но другие пропорции. BufferMapping (31.7%), WALWrite (25.2%), pgpro_stats (20.0%).
§ IO: Абсолютно доминирует DataFileRead (83.5%).
§ Lock: Абсолютно доминирует transactionid (85.8%), ожидания tuple были незначительны.
· Запросы (QueryID):
o Лидеры по типам ожиданий в обоих периодах одни и те же (-5038981907002478858, -4280293605113329019, -1757223094415174739, 7667106468890705260). Это говорит о том, что нагрузка генерируется одним и тем же набором приложений.
o Инцидент:
§ Extension: Основная нагрузка сместилась на запрос -503898190... (33.7%), тогда как в тесте он был на 4-м месте. Два главных запроса теперь генерируют ~59% всех Extension-ожиданий.
§ LWLock: Еще более выраженная концентрация на тех же двух запросах (-503898190... и -428029360...), которые генерируют ~59% всех LWLock-ожиданий.
§ IO и Lock: Появилось большое количество новых запросов в топе, которых не было в тесте (-173829818..., -380964618..., 711182600...). Это указывает на изменение структуры рабочей нагрузки.
Итог по разделу "4. СРАВНЕНИЕ ДИАГРАММ ПАРЕТО ПО WAIT_EVENT_TYPE и QUERYID"
· Усложнение структуры отказов: В инциденте к проблемам с Extension и transactionid (блокировки строк) добавились серьезные проблемы с:
o Конкуренцией за буферный кэш (LWLock: BufferMapping).
o Физическими чтениями данных (IO: DataFileRead).
o Синхронной записью WAL (IO: WALSync).
o Блокировками версий строк (Lock: tuple).
· Концентрация нагрузки: Основные проблемные запросы — прежние, но теперь они создают более сложный и разнообразный профиль ожиданий. Появление новых запросов в топе по IO и Lock говорит о том, что либо начали выполняться новые, тяжелые операции, либо изменился план выполнения старых запросов.
Детальный анализ
Ожидания СУБД
· Инцидент: Рост значимости IO и Lock-ожиданий при сохранении критического уровня LWLocks. Расширения остаются главным по объему типом, но их влияние на общую деградацию скорости ниже, чем у LWLocks.
· Тест: Основные проблемы были связаны с LWLock и Extension. IO и Lock были незначимы.
Память и буферный кэш
· Инцидент: Критическая конкуренция за буферный кэш подтверждается ростом LWLock: BufferMapping до 30% всех LWLock-ожиданий. Это явный признак того, что множество процессов пытаются одновременно получить доступ к разным страницам в буферном кэше, что вызывает пробуксовку.
· Тест: Проблемы с буферным кэшем также были (31.7% LWLock), но, вероятно, система справлялась, так как не было сопутствующих проблем с IO.
Дисковая подсистема (I/O)
· Инцидент: Появление значимых ожиданий IO: DataFileRead (78% всех IO) и IO: WALSync (11%). Это говорит о том, что:
1. Буферный кэш не справляется, и запросам приходится часто читать данные с диска.
2. Синхронная фиксация транзакций (synchronous_commit = remote_write) начала вызывать задержки при записи WAL.
· Тест: Несмотря на наличие DataFileRead, они не коррелировали с общими ожиданиями, т.е. не были узким местом.
CPU и системные вызовы
· Инцидент: Падение cpu_id и рост активности расширений, связанной с прерываниями (Extension <-> in), указывают на то, что CPU тратит такты на обработку прерываний и переключения контекста, инициированные расширениями, в то время как ядро СУБД простаивает в LWLocks.
· Тест: CPU был более свободен, расширения нагружали его полезной работой (us), без лишних прерываний.
Блокировки и ожидания LWLock
· Инцидент: Основная проблема. Высокий ВКО (0.30) и изменившаяся структура:
o Рост LWLock: BufferMapping (конкуренция за кэш).
o Сохранение высокого уровня LWLock: WALWrite и LWLock: pgpro_stats.
o Появление LWLock: LockManager (блокировки в менеджере блокировок) говорит о возросшей сложности управления блокировками.
· Тест: LWLocks также были проблемой, но структура была иной. Высокий R² (0.99) с общими ожиданиями указывает на то, что они были единственной серьезной внутренней проблемой, с которой система справлялась.
Анализ запросов (queryid)
· Инцидент: Запросы -5038981907002478858 и -4280293605113329019 являются главными источниками проблем практически по всем типам ожиданий (LWLock, IO, Lock, Extension). Они требуют немедленной оптимизации.
· Тест: Те же запросы были лидерами, но генерировали менее разрушительный профиль ожиданий.
Ключевые проблемы
Проблемы СУБД
1. Критическая конкуренция за буферный кэш (LWLock: BufferMapping): Является основной причиной падения скорости в инциденте. Процессы проводят время в очередях за доступом к страницам в shared_buffers.
2. Деградация работы расширений (Extension): Расширения стали работать иначе, вызывая всплески прерываний и нагружая CPU, что усугубляет общую ситуацию. Главные виновники — запросы -503898190... и -428029360....
3. Рост физических чтений с диска (IO: DataFileRead): Буферный кэш перестал эффективно кэшировать данные, что привело к падению производительности и росту IO-ожиданий.
4. Появление синхронных проблем с WAL (IO: WALSync): Указывает на то, что запись в WAL начала тормозить транзакции, вероятно, из-за исчерпания пропускной способности диска с WAL или из-за конкурентной записи.
5. Расширение спектра блокировок (Lock: tuple): К проблемам с блокировками транзакций (transactionid) добавились блокировки отдельных версий строк (tuple), что говорит о высоком конкурентном доступе к одному и тому же набору данных.
Проблемы инфраструктуры
1. Неэффективная утилизация CPU: Процессорное время уходит не на полезную работу, а на оверхед (прерывания, ожидания). Это подтверждается падением cpu_id при падении скорости БД.
2. Рост прерываний: Увеличение корреляции Extension с in (прерывания) указывает на возросшую нагрузку на ядро ОС.
3. Косвенные признаки дисковой проблемы: Хотя прямые метрики wa и b улучшились, появление IO: DataFileRead и WALSync в топе ожиданий СУБД говорит о том, что дисковая система перестала справляться с пиковыми нагрузками, даже если это не видно на уровне усредненных метрик vmstat.
4. Острый дефицит свободной памяти: В обоих периодах свободной RAM менее 5% (ALARM). Система постоянно работает на грани нехватки оперативной памяти, что увеличивает вероятность вытеснения страниц и усиливает конкуренцию за буферный кэш. Это фоновый хронический фактор, который, вероятно, и спровоцировал инцидент при изменении паттерна нагрузки.