PG_EXPECTO v.7 + DeepSeek : Статистический анализ инцидента производительности СУБД PostgreSQL - интенсивная запись и дефицит RAM.

Доверь анализ нейросети

GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL

Глоссарий терминов | Postgres DBA | Дзен

ℹ️Представленный документ содержит результаты всестороннего анализа инцидента снижения производительности СУБД PostgreSQL, произошедшего 26 февраля 2026 года. Исследование построено на сравнении двух часовых интервалов: тестового (период штатной работы) и периода самого инцидента. С помощью нейросетевого анализа были обработаны статистические данные по ожиданиям СУБД, метрикам инфраструктуры (vmstat) и профилям запросов, что позволило не только зафиксировать отклонения, но и выявить глубинные корреляционные связи между ними.

В отчете последовательно раскрывается картина деградации: от экспресс-оценки ключевых различий до детального разбора по каждому компоненту системы — от загрузки CPU и состояния памяти до анализа очередей и типов блокировок. Особое внимание уделено изменению структуры ожиданий и появлению нового тяжелого запроса, что в совокупности с критическим дефицитом оперативной памяти привело к перегрузке всех ресурсов. Материал структурирован так, чтобы дать четкое понимание первопричин сбоя и предоставить обоснованную основу для принятия мер по стабилизации работы базы данных.

Инцидент снижения производительности СУБД

• Операционная скорость - снижается📉
• Ожидания СУБД - растут📈

Операционная скорость

Ожидания СУБД

Дата и время инцидента: 2026-02-26 12:24

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

cd /postgres/pg_expecto/sh/load_test/

./incident_report.sh '2026-02-26 12:24'

Результат отчета : исходные файлы для формирования аналитических отчетов с использованием нейросети

1.Экспресс-анализ инцидента СУБД с использованием нейросети

Анализ выполняется путем сравнения статистических показателей за отрезки времени:

• Инцидент: [ Время инцидента - 1 час ; Время инцидента ]
• Тест: [ Время инцидента - 2 часа ; Время инцидента-1час ]

Входные файлы для нейросети:

1. _1.settings.txt: Конфигурационные параметры СУБД и инфраструктуры
2. _2.1.test.postgresql_vmstat.txt: Статистически обработанные данные производительности/ожиданий СУБД и метрик инфраструктуры в тестовый период.
3. _2.postgresql_vmstat.txt: Статистически обработанные данные производительности/ожиданий СУБД и метрик инфраструктуры в период инцидента.

Промпт "_3.2.prompt.short.diff.txt" :

Сформируй краткий сравнительный отчет по производительности СУБД и инфраструктуры:

_2.postgresql_vmstat.txt - ИНЦИДЕНТ ПРОИЗВОДИТЕЛЬНОСТИ СУБД

_2.1.test.postgresql_vmstat.txt - ТЕСТОВЫЙ ОТРЕЗОК ПРОИЗВОДИТЕЛЬНОСТИ СУБД

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

Состав отчета:

# Существенные различия метрик производительностим СУБД и инфраструктуры

# Наиболее вероятная причина снижения производительности СУБД в ходе инцидента

1. Существенные различия метрик производительности СУБД и инфраструктуры

Загрузка CPU

• Тест: us+sy = 23.7% (норма)
• Инцидент: us+sy = 95.7% (ALARM, более 50% времени)

Резкий рост загрузки процессора, почти полное отсутствие простоя (idle упал с 4% до 1%).

Очередь процессов (r)

• Тест: медиана 24, макс 39
• Инцидент: медиана 59, макс 80

Увеличение более чем в 2 раза, 95.7% времени очередь превышает число ядер CPU.

I/O wait (wa)

• Тест: wa >10% в 100% времени, медиана 14%
• Инцидент: wa >10% только в 10.9% времени, медиана 4%

Снижение явных простоев в ожидании ввода-вывода.

Память и подкачка

• Тест: свободная RAM <5% в 100% времени, swap in/out 100% времени
• Инцидент: те же показатели 95.7% (сохраняется острая нехватка памяти и активный свопинг).

Структура ожиданий СУБД (по приоритету ВКО)

• Тест: IPC (0.66 – критический), Timeout (0.01 – низкий)
• Инцидент: IO (0.34 – критический), LWLock (0.17 – высокий), Timeout (0.01), IPC (0.01)

Смещение фокуса с межпроцессного взаимодействия на ввод-вывод и легковесные блокировки.

Запросы-лидеры по ожиданиям

• Тест: один тяжелый запрос (-709787657973380026) – 100% IPC (BufferIo)
• Инцидент: тот же запрос дает 52% IO (DataFileRead/Write), 86% LWLock; появляется новый запрос (-343482726002183894) с 46.6% IO, включая расширение файлов (DataFileExtend) и запись WAL (SlruWrite).

2. Сравнительный статистический анализ (корреляции и регрессии)

Корреляция cs (переключения контекста) с sy (system time)

• Тест: r = 0.49, R² = 0.24 (слабая)
• Инцидент: r = 0.90, R² = 0.82 (очень сильная)

Ядро стало тратить значительно больше времени на переключения контекста.

Корреляция Timeout с r (run queue)

• Тест: отсутствовала (не значима)
• Инцидент: r = 0.98, R² = 0.97 – чрезвычайно сильная связь, указывающая на рост системных таймеров при перегрузке CPU.

Корреляция прочитанных блоков с swap in

• Тест: не значима
• Инцидент: r = 0.87, R² = 0.76 – чтение данных с диска теперь сопровождается подкачкой страниц из swap, прямой признак нехватки памяти.

Корреляция грязных блоков с wa (I/O wait)

• Тест: не значима
• Инцидент: r = 0.87, R² = 0.76 – рост «грязных» страниц теперь вызывает ожидание ввода-вывода.

Корреляция операционной скорости с записанными блоками

• Тест: r = 0.98, R² = 0.97 (очень высокая)
• Инцидент: r = 0.92, R² = 0.84 (остается высокой, но немного снизилась) – производительность по-прежнему сильно зависит от записи.

Корреляция грязных блоков с bo (блоки записи на диск)

• Тест: r = 0.97, R² = 0.94
• Инцидент: r = 0.70, R² = 0.49 – связь ослабла, что может указывать на вмешательство других факторов (например, свопинга).
• Корреляция dirty pages size с bo
• Тест: r = 0.80, R² = 0.64
• Инцидент: r = 0.45, R² = 0.21 – механизмы фоновой записи стали менее эффективны на фоне дефицита памяти.

3. Наиболее вероятная причина снижения производительности

Всплеск интенсивной записи данных на фоне острой нехватки оперативной памяти

В инциденте появился новый тяжелый запрос (-343482726002183894), выполняющий массовые вставки/обновления, что привело к:

• расширению файлов данных (DataFileExtend);
• интенсивной записи в WAL и таблицы (DataFileWrite, SlruWrite);
• росту конкуренции за буферный кэш и WAL (LWLock: BufferContent, WALInsert).

Нехватка памяти (свободная RAM <5%, активный свопинг) заставляет систему вытеснять страницы на диск, увеличивая нагрузку на ввод-вывод и вызывая дополнительные задержки.

CPU оказался перегружен из-за:

• обработки системных вызовов при свопинге;
• роста переключений контекста (корреляция cs–sy);
• активной работы фоновых процессов записи.

Хотя hit ratio остаётся высоким (98.6%), наличие свопинга и корреляции чтения с swap in указывает, что кэш не спасает от подкачки – либо shared_buffers велики относительно доступной RAM, либо другие процессы вытесняют страницы PostgreSQL.

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

2.Детальный анализ инцидента СУБД с использованием нейросети

Анализ выполняется путем сравнения статистических показателей за отрезки времени:

• Инцидент: [ Время инцидента - 1 час ; Время инцидента ]
• Тест: [ Время инцидента - 2 часа ; Время инцидента-1час ]

Входные файлы для нейросети:

1. _1.settings.txt: Конфигурационные параметры СУБД и инфраструктуры
2. _2.1.test.postgresql_vmstat.txt: Статистически обработанные данные производительности/ожиданий СУБД и метрик инфраструктуры в тестовый период.
3. _2.postgresql_vmstat.txt: Статистически обработанные данные производительности/ожиданий СУБД и метрик инфраструктуры в период инцидента.

Промпт "_3.3.prompt.diff.txt" :

Сформируй сводный сравнительный отчет по производительности СУБД и инфраструктуры:

_2.postgresql_vmstat.txt - ИНЦИДЕНТ ПРОИЗВОДИТЕЛЬНОСТИ СУБД

_2.1.test.postgresql_vmstat.txt - ТЕСТОВЫЙ ОТРЕЗОК ПРОИЗВОДИТЕЛЬНОСТИ СУБД

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

Состав отчета:

# Общая информация

# Общий анализ операционной скорости и ожиданий СУБД для "ИНЦИДЕНТ ПРОИЗВОДИТЕЛЬНОСТИ СУБД" и "ТЕСТОВЫЙ ОТРЕЗОК ПРОИЗВОДИТЕЛЬНОСТИ СУБД"

## Сравнительный анализ граничных значений операционной скорости (SPEED) и ожиданий СУБД(WAITINGS)

## Сравнительный анализ трендов операционной скорости (SPEED) и ожиданий СУБД(WAITINGS)

## 1. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД

### Итог по разделу "1. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД"

## 2. СРАВНИТЕЛЬНЫЙ ТРЕНДОВЫЙ АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ vmstat

### Итог по разделу "2. СРАВНИТЕЛЬНЫЙ ТРЕНДОВЫЙ АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ vmstat"

## 3. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД и МЕТРИК vmstat

### Итог по разделу "3. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД и МЕТРИК vmstat"

## 4. СРАВНЕНИЕ ДИАГРАММ ПАРЕТО ПО WAIT_EVENT_TYPE и QUERYID

### Итог по разделу "4. СРАВНЕНИЕ ДИАГРАММ ПАРЕТО ПО WAIT_EVENT_TYPE и QUERYID

# Детальный анализ – граничные значения и корреляции для "ИНЦИДЕНТ ПРОИЗВОДИТЕЛЬНОСТИ СУБД" и "ТЕСТОВЫЙ ОТРЕЗОК ПРОИЗВОДИТЕЛЬНОСТИ СУБД"

## Ожидания СУБД

## Память и буферный кэш

## Дисковая подсистема (I/O)

## CPU и системные вызовы

## Блокировки и ожидания LWLock

## Анализ запросов (queryid)

# Ключевые проблемы для "ИНЦИДЕНТ ПРОИЗВОДИТЕЛЬНОСТИ СУБД" и "ТЕСТОВЫЙ ОТРЕЗОК ПРОИЗВОДИТЕЛЬНОСТИ СУБД"

## Проблемы СУБД

## Проблемы инфраструктуры

Сводный сравнительный отчет по производительности СУБД и инфраструктуры

Общая информация

Период наблюдения (тест): 1 час (60 точек), 2026-02-26 10:24 – 11:24

Период наблюдения (инцидент): 1 час (46 точек), 2026-02-26 11:24 – 12:24

Версия PostgreSQL: 17.5 (в обоих периодах)

Аппаратная конфигурация:

• 8 vCPU (Intel Xeon Skylake, KVM)
• 7.5 GB RAM
• Диски: /data (vdd, 99G), /wal (vdc, 49G), /log (vdb, 29G), корневая группа LVM

Характер нагрузки (тест): преимущественно IPC-ожидания (межпроцессное взаимодействие), умеренная загрузка CPU

Характер нагрузки (инцидент): высокая загрузка CPU, активный свопинг, смещение к IO и LWLock

Общий анализ операционной скорости и ожиданий СУБД

Сравнительный анализ граничных значений операционной скорости (SPEED) и ожиданий СУБД (WAITINGS)

Операционная скорость (SPEED):

• Тест: min 219 575, median 318 760, max 486 300 (условные единицы)
• Инцидент: min 299 814, median 521 215, max 548 900

Вывод: В инциденте скорость значительно выше (медиана выросла на ~63%), но разброс меньше; возможно, система работает на пределе.

Суммарные ожидания (WAITINGS):

• Тест: min 23 545, median 28 132, max 32 260
• Инцидент: min 12 232, median 15 751, max 25 239

Вывод: Общие ожидания снизились почти вдвое (медиана упала на 44%), что необычно при росте скорости. Это может указывать на изменение характера ожиданий (меньше событий, но более длительных).

Сравнительный анализ трендов операционной скорости и ожиданий СУБД

Тренд операционной скорости (R²):

• Тест: R² = 0.94 (очень сильный), угол +44.15 (рост)
• Инцидент: R² = 0.67 (хороший), угол -39.33 (падение)

Вывод: В тесте скорость устойчиво росла, в инциденте – столь же устойчиво падала.

Тренд ожиданий СУБД (R²):

• Тест: R² = 0.68 (хороший), угол -39.55 (снижение)
• Инцидент: R² = 0.43 (средний), угол +33.20 (рост)

Вывод: В тесте ожидания снижались одновременно с ростом скорости (хорошая динамика). В инциденте ожидания росли, а скорость падала – классический признак деградации.

Регрессия скорости по ожиданиям:

• Тест: R² = 0.63, угол -38.5 (сильная обратная связь)
• Инцидент: R² = 0.54, угол -36.3 (средняя обратная связь)

Вывод: Обратная зависимость сохраняется, но в инциденте модель стала слабее, вероятно, из-за влияния других факторов (память, CPU).

1. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД

Ключевые типы ожиданий (по приоритету ВКО):

Тест:

1. IPC (ВКО = 0.66 – критический) – доминирует, объясняет 92% вариации ожиданий.

2. Timeout (ВКО = 0.01 – низкий) – игнорируется.

Инцидент:

1. IO (ВКО = 0.34 – критический) – 43% вариации.

2. LWLock (ВКО = 0.17 – высокий) – 39% вариации.

3. Timeout (ВКО = 0.01 – низкий) – 46% вариации (но ВКО мал).

4. IPC (ВКО = 0.01 – низкий) – 21% вариации (но ВКО мал).

Сравнение:

• В тесте главная проблема – межпроцессное взаимодействие (IPC), связанное с фоновыми процессами, репликацией.
• В инциденте на первое место выходят ожидания ввода-вывода (IO) и легковесные блокировки (LWLock), что указывает на дисковый и конкурентный характер проблем.

Итог по разделу

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

2. СРАВНИТЕЛЬНЫЙ ТРЕНДОВЫЙ АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ vmstat

procs -> r (очередь на CPU):

• Тест: R² = 0.94, угол +44.07 (сильный рост), медиана 24 → макс 39
• Инцидент: R² = 0.98, угол +44.70 (сильный рост), медиана 59 → макс 80

Вывод: Очередь процессов в инциденте значительно выше (медиана 59 против 24) и продолжает расти – CPU перегружен.

procs -> b (процессы в I/O wait):

• Тест: R² = 0.88, угол +43.22 (рост), медиана 3 → макс 4
• Инцидент: R² = 0.73, угол -40.58 (снижение), медиана 4 (макс 4)

Вывод: В инциденте количество процессов, заблокированных по I/O, немного снижается – возможно, потому что они уже не могут запуститься из-за нехватки CPU или памяти.

cpu -> wa (I/O wait):

• Тест: R² = 0.24 (слабый), wa >10% в 100% времени, медиана 14%
• Инцидент: R² = 0.72 (хороший, падение), wa >10% в 10.9% времени, медиана 4%

Вывод: В тесте высокий I/O wait, в инциденте он резко упал – это не означает улучшения, а скорее свидетельствует о том, что CPU занят другой работой (us/sy), и I/O wait просто не успевает проявиться.

cpu -> id (idle):

• Тест: R² = 0.82, угол -42.08 (сильное падение), медиана 4% → макс 10%
• Инцидент: R² = 0.75, угол -40.86 (падение), медиана 1% → макс 2%

Вывод: Простой CPU в инциденте практически отсутствует (медиана 1%), что подтверждает полную утилизацию.

Итог по разделу

• В инциденте наблюдается критическая перегрузка CPU (очередь r > 50, idle ~1%), при этом I/O wait невысок, что типично для сценария, когда процессы не ждут диск, а конкурируют за процессор или память.
• В тесте, наоборот, CPU был менее загружен, но больше времени проводил в ожидании ввода-вывода.

3. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД и МЕТРИК vmstat

Относительные показатели vmstat:

• us+sy >80%: Тест – 23.7% (норма), Инцидент – 95.7% (ALARM)
• r > ядер CPU: Тест – 94.9% (ALARM), Инцидент – 95.7% (ALARM, но значения выше)
• free RAM <5%: Тест – 100% (ALARM), Инцидент – 95.7% (ALARM)
• swap in/out: Тест – 100% (ALARM), Инцидент – 95.7% (ALARM)
• wa >10%: Тест – 100% (ALARM), Инцидент – 10.9% (OK)

Корреляции с типами ожиданий СУБД:

Тест: Значимые корреляции отсутствуют между IPC/Timeout и метриками vmstat ожидания IPC не связаны напрямую с системными счетчиками.

Инцидент:

• Timeout сильно коррелирует с r (r=0.98, R²=0.97) – рост таймерных ожиданий при перегрузке CPU.
• Другие типы (IO, LWLock) не показали значимых корреляций с vmstat-метриками, что может указывать на внутренние причины СУБД.

Анализ метрик vmstat между собой:

cs (context switches) и in (interrupts): в обоих периодах очень высокая корреляция (R²~0.97 в тесте, 0.97 в инциденте) – норма.

cs и sy (system time):

• Тест: r=0.49, R²=0.24 (слабая)
• Инцидент: r=0.90, R²=0.82 (очень сильная)

Вывод: В инциденте переключения контекста стали тесно связаны с затратами системного времени – ядро тратит ресурсы на планирование.

Анализ I/O:

Скорость и записанные блоки:

• Тест: r=0.98, R²=0.97
• Инцидент: r=0.92, R²=0.84

Вывод: Запись остаётся узким местом в обоих случаях.

Прочитанные блоки и swap in:

• Тест: корреляция не значима
• Инцидент: r=0.87, R²=0.76 – чтение с диска теперь сопровождается подкачкой из swap (нехватка памяти).

Грязные блоки и wa:

• Тест: не значимо
• Инцидент: r=0.87, R²=0.76 – рост dirty pages вызывает I/O wait (диск не успевает).

Hit ratio и us:

• Тест: r=-0.77, R²=0.59 (обратная связь)
• Инцидент: r=-0.75, R²=0.57 – сохраняется, но в инциденте hit ratio остаётся высоким (~98.6%), что при активном свопинге говорит о вытеснении кэша.

Анализ dirty pages:

Размер dirty pages:

• Тест: медиана 6.3 МБ, макс 27.7 МБ
• Инцидент: медиана 59.8 МБ, макс 80.9 МБ (рост в 10 раз)

Корреляция dirty pages с b (uninterruptible sleep):

• Тест: r=0.74, R²=0.54 (средняя)
• Инцидент: не значима – процессы уже не ждут I/O, а конкурируют за CPU.

Корреляция dirty pages с bo:

• Тест: r=0.80, R²=0.64
• Инцидент: r=0.45, R²=0.21 (слабая) – механизм фоновой записи работает хуже.

Корреляция dirty pages с sy:

• Тест: r=0.80, R²=0.63
• Инцидент: не значима – системное время теперь связано с переключениями контекста, а не с dirty pages.

Итог по разделу

• Тест: Система испытывает нехватку памяти (свопинг, dirty pages умеренные), но CPU не перегружен. Основные корреляции указывают на зависимость от записи и dirty pages.
• Инцидент: Нехватка памяти усугубилась, dirty pages выросли в 10 раз, но корреляции сместились: теперь главные факторы – перегрузка CPU, рост контекстных переключений, связь чтения с подкачкой и грязных страниц с I/O wait. Диск не справляется с записью, но процессы чаще блокируются не на I/O, а на конкуренции за ресурсы.

4. СРАВНЕНИЕ ДИАГРАММ ПАРЕТО ПО WAIT_EVENT_TYPE и QUERYID

Тест:

• Доминирующий тип ожиданий: IPC (100% у запроса -709787657973380026, событие BufferIo) – 367k ожиданий.
• Второстепенный: Timeout (SpinDelay) – 24.7k ожиданий у того же запроса.

Вывод: Один тяжёлый запрос генерирует почти все ожидания IPC, связанные с BufferIo (ожидание освобождения буфера ввода-вывода? но BufferIo относится к IO? Возможно, неточность в отчёте).

Инцидент:

Типы ожиданий распределены по нескольким запросам:

• IO: запрос -709787657973380026 (52% ожиданий, DataFileRead/Write) и новый запрос -343482726002183894 (46.6%, DataFileExtend, DataFileRead/Write, SlruWrite).
• LWLock: запрос -709787657973380026 (86% ожиданий, множество событий: BufferContent, WALInsert и др.)
• Timeout: запрос -709787657973380026 (91%, SpinDelay)
• IPC: запрос -709787657973380026 (100%, BufferIo)

Вывод: Появился новый запрос с массовыми расширениями файлов и записью WAL, что объясняет рост IO и LWLock. Старый запрос теперь вызывает не только IPC, но и IO, LWLock – его характер изменился или нагрузка возросла.

Итог по разделу

• В тестовом периоде проблема локализована в одном запросе, вызывающем IPC-ожидания (вероятно, связанные с репликацией или фоновыми процессами).
• В инциденте добавился второй тяжёлый запрос, который генерирует интенсивную запись и расширение данных, что приводит к блокировкам LWLock и ожиданиям ввода-вывода. Старый запрос также стал более ресурсоёмким по разным типам.

Детальный анализ – граничные значения и корреляции

Ожидания СУБД

Тип ожидания – IO

• Тест: медиана 5 667, максимум 7 211
• Инцидент: медиана 10 230, максимум 12 428

Изменение: +80%

Тип ожидания – IPC

• Тест: медиана 21 195, максимум 23 716
• Инцидент: медиана 6, максимум 14 582 (редкий всплеск)

Изменение: резкое падение (кроме пика)

Тип ожидания – LWLock

• Тест: медиана 1 752, максимум 3 313
• Инцидент: медиана 5 187, максимум 6 760

Изменение: +196%

Тип ожидания – Timeout

• Тест: медиана 141, максимум 383
• Инцидент: медиана 144, максимум 178

Изменение: +2%

Вывод: В инциденте резко выросли IO и LWLock, а IPC практически исчез (кроме одного всплеска в конце периода – 14 582).

Память и буферный кэш

Hit ratio (shared buffers):

• Тест: медиана 98.22% (min 70.4%, max 98.5%)
• Инцидент: медиана 98.61% (min 98.2%, max 98.7%)

Вывод: Формально hit ratio высок в обоих случаях, но в тесте были провалы до 70% – возможно, периодические чтения больших объёмов. В инциденте hit ratio стабильно высокий, несмотря на свопинг.

Свободная RAM (<5%):

• Тест: 100% времени
• Инцидент: 95.7% времени

Вывод: Постоянный дефицит памяти в обоих периодах.

Swap in/out:

• Тест: 100% времени
• Инцидент: 95.7% времени

Вывод: Активный свопинг присутствует всегда.

Корреляция чтения с swap in:

• Появилась только в инциденте (сильная), что указывает на усугубление нехватки памяти.

Дисковая подсистема (I/O)

Записанные блоки (io_bo):

• Тест: медиана 16 857, макс 21 521
• Инцидент: медиана 21 546, макс 21 791

Вывод: Запись выросла на ~28% (медиана), что совпадает с ростом IO-ожиданий.

Прочитанные блоки (io_bi):

• Тест: медиана 69 201, макс 111 483
• Инцидент: медиана 46 134, макс 52 544

Вывод: Чтение снизилось почти на 33%, возможно, из-за того, что данные уже в кэше (hit ratio высок) или запросы стали более write-oriented.

Корреляция скорости с записью:

• Остаётся очень высокой в обоих случаях, подтверждая, что производительность ограничена записью.

Корреляция грязных блоков с wa:

• Появилась только в инциденте (сильная) – диск не успевает сбрасывать dirty pages.

Размер dirty pages:

• Вырос в 10 раз в инциденте, достигнув 80 МБ (что при 7.5 ГБ RAM составляет ~1% – допустимо, но в сочетании со свопингом указывает на проблемы с фоновой записью).

CPU и системные вызовы

us (user time):

• Тест: медиана 67%, макс 72%
• Инцидент: медиана 82%, макс 85%

Вывод: Рост user time на 22%, что соответствует более тяжёлым запросам.

sy (system time):

• Тест: медиана 10%, макс 11%
• Инцидент: медиана 11%, макс 12%

Вывод: Небольшой рост, но корреляция cs–sy стала очень сильной – системное время теперь тратится на переключения контекста.

cs (context switches):

• Тест: медиана 21 263, макс 24 822
• Инцидент: медиана 25 443, макс 26 316

Вывод: Рост переключений на ~20%.

in (interrupts):

• Тест: медиана 18 350, макс 22 613
• Инцидент: медиана 23 663, макс 24 504

Вывод: Рост прерываний на ~29%.

Очередь r:

• Выросла более чем вдвое, достигнув 80 при 8 ядрах – явный признак перегрузки CPU.

Блокировки и ожидания LWLock

LWLock-ожидания:

• Выросли почти в 3 раза (медиана 1 752 → 5 187).
• В инциденте появились события: BufferContent, WALInsert, ProcArray и др., указывающие на конкуренцию за буферный кэш и WAL.
• Запрос -709787657973380026 стал главным потребителем LWLock (86% всех ожиданий этого типа).

Анализ запросов (queryid)

Запрос -709787657973380026:

• Тест: 365 вызовов, 367k ожиданий IPC (BufferIo)
• Инцидент: 297 вызовов, 305k ожиданий IO (DataFileRead/Write), 843k ожиданий LWLock (множество событий), 580k ожиданий IPC (BufferIo)

Вывод: Запрос стал выполняться реже (с 365 до 297), но генерирует гораздо больше ожиданий разных типов – вероятно, из-за изменения плана или объёма данных.

Запрос -343482726002183894:

• Появился только в инциденте: 1.535 млн вызовов, 272k ожиданий IO (DataFileExtend, DataFileRead/Write, SlruWrite).

Вывод: Это новый высокочастотный запрос на запись/расширение данных, создающий основную нагрузку на I/O и WAL.

Ключевые проблемы

Проблемы СУБД

1. Смена характера ожиданий: с IPC (тест) на IO и LWLock (инцидент). Это говорит о переходе от проблем взаимодействия процессов к реальным дисковым и блокировочным конфликтам.

2. Появление нового тяжёлого запроса (-343482726002183894) с массовыми расширениями файлов и записью WAL, что привело к:

• Росту IO-ожиданий (DataFileExtend, DataFileWrite)
• Увеличению грязных страниц и давления на фоновую запись
• Конкуренции за WAL (ожидания WALInsert)

3. Старый запрос (-709787657973380026) стал источником множества LWLock-ожиданий (BufferContent, WALInsert, ProcArray), указывая на внутреннюю конкуренцию за общие структуры памяти.

4. Высокий hit ratio при активном свопинге – парадокс, который объясняется тем, что кэш СУБД (shared_buffers) ещё помещается в память, но ОС вынуждена подкачивать другие страницы, что создаёт дополнительную нагрузку на I/O при чтении с диска.

Проблемы инфраструктуры

1. Критическая нехватка оперативной памяти:

• Свободная RAM <5% почти всё время.
• Постоянный свопинг (in/out) – в инциденте 95.7% времени.
• Появилась сильная корреляция чтения с диска с подкачкой из swap – признак того, что системе не хватает памяти для кэширования данных, и чтения вызывают вытеснение страниц.

2. Перегрузка CPU:

• Очередь процессов на CPU (r) достигает 80 при 8 ядрах (в 10 раз выше нормы).
• Загрузка us+sy >95% практически всё время.
• Резкий рост переключений контекста и их сильная связь с системным временем (cs–sy) – ядро тратит ресурсы на планирование, а не на полезную работу.

3. Дисковая подсистема не справляется с записью:

• Корреляция скорости с записью остаётся очень высокой – узкое место.
• Размер dirty pages вырос в 10 раз, появилась корреляция dirty pages с I/O wait.
• Фоновые механизмы записи (dirty pages → bo) работают хуже (R² упал с 0.64 до 0.21).

4. I/O wait снизился, но не из-за улучшений, а из-за того, что CPU занят другими задачами. Это маскирует проблемы диска, но не устраняет их.

Общий вывод:

Инцидент вызван сочетанием увеличения объёмов записи (новый запрос) и острого дефицита памяти, что привело к перегрузке CPU (из-за свопинга и конкуренции), росту блокировок LWLock и падению скорости. Тестовый период демонстрировал те же проблемы с памятью, но нагрузка на запись была ниже, и CPU ещё справлялся. Для стабилизации необходимо увеличить RAM, оптимизировать новый запрос и, возможно, ускорить диск или отделить WAL.

Послесловие

Представленный анализ подтверждает, что корень инцидента кроется в системной проблеме, вызванной сочетанием острой нехватки оперативной памяти и появлением ресурсоемкого запроса на запись, что привело к эффекту «домино»: дефицит памяти спровоцировал свопинг, который перегрузил процессор и заблокировал дисковую подсистему, изменив структуру ожиданий с межпроцессного взаимодействия на блокировки ввода-вывода. Для стабилизации работы СУБД необходима не просто локальная оптимизация проблемного запроса, а комплексное решение: увеличение объема RAM для исключения подкачки и, возможно, разгрузка дисковой подсистемы путем вынесения WAL на более быстрое хранилище.