GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL
Глоссарий терминов | Postgres DBA | Дзен
ℹ️Представленный отчет содержит результаты сравнительного анализа инцидента снижения производительности СУБД PostgreSQL, зафиксированного 25 февраля 2026 года. Исследование базируется на сопоставлении метрик операционной скорости, ожиданий (wait events) и инфраструктурных показателей (vmstat) в течение двух смежных часовых интервалов: тестового (стабильная работа) и периода инцидента. Целью анализа является выявление статистически значимых изменений в поведении системы и определение корневой причины деградации скорости выполнения запросов с использованием методов корреляционного и трендового анализа.
➡️Ключевой вывод, подтвержденный количественными данными, — смена характера дисковой нагрузки. В то время как в тестовом периоде основным драйвером ожиданий ввода-вывода являлись операции записи, в ходе инцидента доминирующим фактором стало физическое чтение с диска. Это изменение, наряду с критическим снижением объема свободной оперативной памяти и усилением зависимости «грязных» страниц от нее, указывает на нехватку буферного кэша и переход системы в режим интенсивного ожидания дисковой подсистемы, что и привело к падению операционной скорости.
Инцидент снижения производительности СУБД
- Операционная скорость - снижается📉
- Ожидания СУБД - растут📈
Операционная скорость
Ожидания СУБД
Дата и время инцидента: 2026-02-25 15:58
Сбор статистической информации о производительности-ожиданиях СУБД и метриках инфраструктуры
cd /postgres/pg_expecto/sh/load_test/
./incident_report.sh '2026-02-25 15:58'
Результат отчета : исходные файлы для формирования аналитических отчетов с использованием нейросети
1.Экспресс-анализ инцидента СУБД с использованием нейросети
Анализ выполняется путем сравнения статистических показателей за отрезки времени:
- Инцидент: [ Время инцидента - 1 час ; Время инцидента ]
- Тест: [ Время инцидента - 2 часа ; Время инцидента-1час ]
Входные файлы для нейросети:
- _1.settings.txt: Конфигурационные параметры СУБД и инфраструктуры
- _2.1.test.postgresql_vmstat.txt: Статистически обработанные данные производительности/ожиданий СУБД и метрик инфраструктуры в тестовый период.
- _2.postgresql_vmstat.txt: Статистически обработанные данные производительности/ожиданий СУБД и метрик инфраструктуры в период инцидента.
Промпт "_3.2.prompt.short.diff.txt" :
Сформируй краткий сравнительный отчет по производительности СУБД и инфраструктуры:
_2.postgresql_vmstat.txt - ИНЦИДЕНТ ПРОИЗВОДИТЕЛЬНОСТИ СУБД
_2.1.test.postgresql_vmstat.txt - ТЕСТОВЫЙ ОТРЕЗОК ПРОИЗВОДИТЕЛЬНОСТИ СУБД
Для формирования отчета используй списки, вместо таблиц.
Состав отчета:
# Существенные различия метрик производительностим СУБД и инфраструктуры
# Наиболее вероятная причина снижения производительности СУБД в ходе инцидента
1. Существенные различия метрик производительности СУБД и инфраструктуры
Динамика операционной скорости
- Тестовый отрезок: скорость демонстрирует слабый положительный тренд (R² = 0,27, угол +27,25).
- Инцидент: скорость падает с хорошей достоверностью (R² = 0,70, угол –39,83).
Объём ожиданий СУБД
- Медиана ожиданий выросла с 830 955 (тест) до 928 446 (инцидент), при этом тренд роста остаётся очень сильным в обоих случаях (R² ~0,98).
Характер связи скорости и ожиданий
- Тест: связь отсутствует или положительная, модель слабая (R² = 0,24).
- Инцидент: чёткая отрицательная корреляция (–0,804), модель хорошая (R² = 0,65).
Типы ожиданий
- В обоих периодах доминирует IO (интегральный приоритет 0,6271). Однако в тесте IO сильно связан с записью на диск (bo: r = 0,815, R² = 0,66), а в инциденте — с чтением с диска (bi: r = 0,515, R² = 0,27), связь с записью исчезает.
Метрики vmstat (процессы и I/O)
- procs r (очередь на CPU): медиана выросла с 9 до 14, в инциденте 100% времени превышает число ядер (8). Тренд r стал достоверным (R² = 0,58 против 0,18 в тесте).
- procs b (процессы в uninterruptible sleep): медиана увеличилась с 152 до 177, тренд остаётся крайне сильным в обоих случаях (R² ~0,98).
- wa (iowait): медиана снизилась с 31% до 28%, но в инциденте тренд снижения wa замедлился (угол –19,16 против –41,09 в тесте).
Грязные страницы (dirty pages)
- Медиана размера dirty pages уменьшилась с ~14,8 МБ (тест) до ~11,0 МБ (инцидент).
- Связь dirty pages со свободной памятью (free) усилилась: в тесте R² = 0,46, в инциденте R² = 0,76.
- Связь dirty pages с wa остаётся значимой, но коэффициент детерминации снизился (0,73 → 0,54).
Приоритеты корреляций (CPI)
- Тест: лидируют связи cs–in, cs–us, dirty–wa.
- Инцидент: на первое место выходит связь dirty–free, затем скорость–записанные блоки, dirty–wa, появляется корреляция hit–us.
Нагрузка по запросам
- В обоих случаях основным источником IO является один и тот же запрос ( queryid -709787657973380026), его доля в общих ожиданиях IO практически неизменна (~87,2%).
2. Сравнительный статистический анализ метрик производительности
Тренд скорости (R²):
- Тестовый отрезок: 0,27 (слабый)
- Инцидент: 0,70 (хороший)
Изменение: появление достоверного падения скорости.
Тренд ожиданий (R²):
- Тест: 0,97 (очень высокий)
- Инцидент: 0,98 (очень высокий)
Изменение: сохраняется устойчивый рост ожиданий.
Корреляция скорость–ожидания (r):
- Тест: отсутствует / положительная
- Инцидент: –0,804 (отрицательная)
Изменение: переход к обратной зависимости (рост ожиданий → падение скорости).
R² регрессии скорость–ожидания:
- Тест: 0,24 (непригодная модель)
- Инцидент: 0,65 (хорошая модель)
Изменение: установлена причинно-следственная связь.
Корреляция IO–bi (чтение):
- Тест: незначима
- Инцидент: 0,515 (R² = 0,27)
Изменение: появление вклада чтений в IO-ожидания.
Корреляция IO–bo (запись):
- Тест: 0,815 (R² = 0,66)
- Инцидент: незначима
Изменение: исчезновение связи с записью.
Корреляция dirty–free (r):
- Тест: –0,680 (R² = 0,46)
- Инцидент: –0,872 (R² = 0,76)
Изменение: усиление зависимости dirty pages от свободной памяти.
Корреляция dirty–wa (r):
- Тест: 0,856 (R² = 0,73)
- Инцидент: 0,733 (R² = 0,54)
Изменение: снижение, но сохранение значимости.
Корреляция hit–us:
- Тест: незначима
- Инцидент: –0,669 (R² = 0,45)
Изменение: появление связи попаданий в кэш с пользовательским временем CPU.
procs r тренд (R²):
- Тест: 0,18 (неудовлетворительный)
- Инцидент: 0,58 (удовлетворительный)
Изменение: рост очереди на CPU стал статистически значимым.
procs b тренд (R²):
- Тест: 0,99
- Инцидент: 0,98
Изменение: стабильно высокий рост числа заблокированных процессов (ожидание I/O)
3. Наиболее вероятная причина снижения производительности СУБД в ходе инцидента
⚠️Изменение характера дисковой нагрузки с преимущественно записи на чтение
ℹ️В тестовом периоде рост ожиданий IO был обусловлен операциями записи (сильная корреляция с bo), что характерно для контрольных точек или фоновой записи dirty pages.
⚠️В инциденте связь IO с записью исчезает, но появляется корреляция с чтением (bi), при этом размер dirty pages снижается, а их зависимость от свободной памяти резко усиливается. ➡️ Это указывает на то, что система памяти находится под давлением: свободная память минимальна, кэш заполнен, и запросы на чтение данных, не помещающихся в shared buffers, вызывают физические чтения с диска.
Дополнительные факторы:
- Рост очереди процессов на выполнение (r) и числа процессов в uninterruptible sleep (b) подтверждает перегрузку дисковой подсистемы.
- Появление корреляции hit–us говорит о том, что даже при высоком hit ratio (99,3%) часть запросов требует интенсивной работы CPU, возможно, из-за неоптимальных планов или увеличения сложности обработки.
⚠️Таким образом, основной причиной падения производительности стало увеличение доли операций физического чтения, вызванное нехваткой памяти и/или изменением паттерна запросов (например, более тяжёлые сценарии чтения), что привело к росту ожиданий IO и, как следствие, к снижению операционной скорости.
2.Детальный анализ инцидента СУБД с использованием нейросети
Анализ выполняется путем сравнения статистических показателей за отрезки времени:
- Инцидент: [ Время инцидента - 1 час ; Время инцидента ]
- Тест: [ Время инцидента - 2 часа ; Время инцидента-1час ]
Входные файлы для нейросети:
- 1.settings.txt: Конфигурационные параметры СУБД и инфраструктуры
- _2.1.test.postgresql_vmstat.txt: Статистически обработанные данные производительности/ожиданий СУБД и метрик инфраструктуры в тестовый период.
- _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)
# Ключевые проблемы для "ИНЦИДЕНТ ПРОИЗВОДИТЕЛЬНОСТИ СУБД" и "ТЕСТОВЫЙ ОТРЕЗОК ПРОИЗВОДИТЕЛЬНОСТИ СУБД"
## Проблемы СУБД
## Проблемы инфраструктуры
Сводный сравнительный отчет по производительности СУБД и инфраструктуры
Общая информация
Периоды анализа:
- Тестовый отрезок: 2026-02-25 13:58 – 14:58 (1 час)
- Инцидент производительности: 2026-02-25 14:58 – 15:58 (1 час)
Аппаратная конфигурация:
- CPU: 8 ядер (Intel Xeon Skylake, виртуализация KVM)
- RAM: 7.5 GB
- Диски: отдельные LVM-тома для данных (/data), WAL (/wal), логов (/log)
Версия PostgreSQL: 17.5
Общий анализ операционной скорости и ожиданий СУБД
Сравнительный анализ граничных значений операционной скорости (SPEED) и ожиданий СУБД (WAITINGS)
SPEED (операций в единицу времени):
- Тест: минимум 1 072 765, медиана 1 080 895, максимум 1 107 749
- Инцидент: минимум 1 065 101, медиана 1 081 262, максимум 1 113 329
Изменение: медиана практически не изменилась (+0,03%), но разброс увеличился.
WAITINGS (общие ожидания):
- Тест: минимум 785 160, медиана 830 955, максимум 882 189
- Инцидент: минимум 880 868, медиана 928 446, максимум 982 293
Изменение: медиана выросла на 11,7%.
Ожидания по типам (медианы):
- IO (доминирующий тип): тест 829 037, инцидент 926 112 (+11,7%)
- IPC: тест 146, инцидент 196 (+34%)
- LOCK: тест 1 189, инцидент 1 435 (+20,7%)
- LWLOCK: тест 507, инцидент 636 (+25,4%)
- TIMEOUT: тест 95, инцидент 100 (+5,3%)
Сравнительный анализ трендов операционной скорости (SPEED) и ожиданий СУБД (WAITINGS)
Тренд SPEED:
- Тест: слабый положительный (R² = 0,27, угол +27,25)
- Инцидент: хороший отрицательный (R² = 0,70, угол –39,83) – скорость достоверно падает.
Тренд WAITINGS:
- Тест: очень сильный рост (R² = 0,97, угол +44,63)
- Инцидент: очень сильный рост (R² = 0,98, угол +44,70)
Вывод: рост ожиданий сохраняется с одинаковой скоростью.
Регрессия SPEED по WAITINGS:
- Тест: модель слабая, положительная связь (R² = 0,24, угол +25,93)
- Инцидент: модель хорошая, отрицательная связь (R² = 0,65, угол –38,80; корреляция r = –0,804)
Вывод: в инциденте рост ожиданий стал непосредственной причиной падения скорости.
1. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД
Тип IO:
В обоих периодах имеет интегральный приоритет ВКО = 1,0000 (критический).
- Тест: IO сильно коррелирует с записью на диск (bo: r = 0,815, R² = 0,66).
- Инцидент: IO коррелирует с чтением с диска (bi: r = 0,515, R² = 0,27), связь с записью исчезает.
Типы IPC, LOCK, LWLOCK:
- Имеют высокие корреляции с общими ожиданиями (r ~ 0,9), но ВКО < 0,01 – игнорируются как незначимые.
- Абсолютные значения выросли на 20–35%, что может указывать на рост внутренней конкуренции.
Итог по разделу "1. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД"
- Единственный критический тип ожиданий – IO.
- Характер IO изменился: от записи (тест) к чтению (инцидент).
2. СРАВНИТЕЛЬНЫЙ ТРЕНДОВЫЙ АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ vmstat
procs r (очередь на CPU):
- Тест: R² = 0,18 (неудовлетворительный), тренд слабый.
- Инцидент: R² = 0,58 (удовлетворительный), тренд роста стал достоверным.
procs b (процессы в uninterruptible sleep, ожиданиеI/O):
- Тест: R² = 0,99, угол +44,83 (очень сильный рост)
- Инцидент: R² = 0,98, угол +44,70 (очень сильный рост)
Вывод: число процессов, заблокированных по I/O, растёт с одинаково высокой скоростью.
cpu wa (iowait):
- Тест: R² = 0,76, угол –41,09 (хорошее снижение)
- Инцидент: R² = 0,53, угол –36,08 (удовлетворительное снижение, но замедлилось)
cpu id (idle):
- В обоих случаях R² = 0 – тренда нет, idle всегда 0%.
Итог по разделу "2. СРАВНИТЕЛЬНЫЙ ТРЕНДОВЫЙ АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ vmstat"
- Основной тренд – неуклонный рост числа процессов, ожидающих I/O (b).
- В инциденте добавился достоверный рост очереди на CPU (r), а снижение iowait замедлилось.
3. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД И МЕТРИК vmstat
IO – bi (чтение):
- Тест: незначимо
- Инцидент: r = 0,515, R² = 0,27 (появилась связь с чтением)
IO – bo (запись):
- Тест: r = 0,815, R² = 0,66 (сильная связь)
- Инцидент: незначимо (связь потеряна)
Скорость – записанные блоки:
- Тест: r = 0,688, R² = 0,47
- Инцидент: r = 0,762, R² = 0,58 (связь усилилась)
Скорость – прочитанные блоки:
- Тест: незначимо
- Инцидент: r = 0,460, R² = 0,21 (слабая связь)
dirty pages – wa:
- Тест: r = 0,856, R² = 0,73
- Инцидент: r = 0,733, R² = 0,54 (связь сохраняется, но ослабла)
dirty pages – free RAM:
- Тест: r = –0,680, R² = 0,46
- Инцидент: r = –0,872, R² = 0,76 (связь резко усилилась)
hit ratio – us (user time):
- Тест: незначимо
- Инцидент: r = –0,669, R² = 0,45 (появилась обратная связь)
cs (context switches) – in (прерывания):
- Тест: r = 0,935, R² = 0,87
- Инцидент: незначимо
cs – us:
- Тест: r = 0,889, R² = 0,79
- Инцидент: незначимо
Итог по разделу "3. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД И МЕТРИК vmstat"
- В инциденте произошло смещение фокуса: IO теперь связано с чтением, а не с записью.
- Усилилась зависимость dirty pages от свободной памяти.
- Появилась связь hit–us, указывающая на влияние пользовательской активности на попадания в кэш.
- Исчезли сильные корреляции cs–in и cs–us – переключения контекста перестали быть драйвером системы.
4. СРАВНЕНИЕ ДИАГРАММ ПАРЕТО ПО WAIT_EVENT_TYPE И QUERYID
Тип ожидания:
- В обоих периодах IO имеет интегральный приоритет 0,6271.
Основной проблемный запрос:
- Queryid: -709787657973380026 (SQL: select scenario1())
- Доля в общих ожиданиях IO: тест 87,19%, инцидент 87,23% (практически неизменна).
- Абсолютное число ожиданий от этого запроса: тест ~40,1 млн, инцидент ~43,3 млн (+8%).
Итог по разделу "4. СРАВНЕНИЕ ДИАГРАММ ПАРЕТО ПО WAIT_EVENT_TYPE И QUERYID"
- Проблемный запрос не изменился, его доля стабильна, но абсолютная нагрузка от него выросла пропорционально общему росту ожиданий.
Детальный анализ – граничные значения и корреляции
Ожидания СУБД
- Медиана WAITINGS выросла на 11,7% за счёт роста IO.
- IPC, LOCK, LWLOCK выросли на 20–35%, но их вклад в общие ожидания остаётся ниже 0,2%.
Память и буферный кэш
shared_buffers hit ratio:
- Тест: min 99,287%, median 99,319%, max 99,327%
- Инцидент: min 99,307%, median 99,313%, max 99,327%
Изменение: практически не изменился, остаётся на уровне 99,3%.
Свободная RAM (free memory):
- Медиана упала с 750,5 MB (тест) до 477 MB (инцидент) – снижение на 36%.
- 100% времени свободная RAM < 5% (ALARM).
Dirty pages size:
- Медиана снизилась с 14 770 KB (тест) до 10 998 KB (инцидент) – на 25%.
- Корреляция dirty–free усилилась (R² 0,46 → 0,76), указывая на тесную связь dirty pages с дефицитом памяти.
- Появление корреляции hit–us (R² 0,45) говорит о том, что рост user time сопровождается падением попаданий в кэш.
Дисковая подсистема (I/O)
- IO–bi стала значимой в инциденте (r = 0,515), указывая на рост физических чтений.
- IO–bo потеряла значимость – запись перестала быть основным драйвером IO.
- Скорость–записанные блоки сохраняет сильную отрицательную связь (r = –0,762), т.е. запись по-прежнему тормозит систему.
- wa (iowait) снизилась с 31% до 28%, но её тренд замедлился.
- b (процессы в uninterruptible sleep) продолжает расти с высокой скоростью.
CPU и системные вызовы
- procs r выросла (медиана 9 → 14), и в инциденте 100% времени превышает число ядер (ALARM).
- us (user time) выросла с 52% до 56% (медиана).
- sy (system time) осталась на уровне 13–14%.
Исчезновение корреляций cs–in и cs–us говорит о том, что система перешла в режим ожидания I/O, а не активных вычислений.
Блокировки и ожидания LWLock
- Рост LOCK (+20%) и LWLOCK (+25%) при сохранении высоких корреляций с общими ожиданиями (r ~ 0,9) может быть следствием, а не причиной, но требует мониторинга.
Анализ запросов (queryid)
- Основной вклад вносит запрос select scenario1() (около 87% всех ожиданий IO).
- Рост его абсолютных ожиданий (+8%) соответствует общему росту WAITINGS.
Ключевые проблемы
Проблемы СУБД
1. Доминирование одного запроса
- Запрос scenario1 генерирует ~87% всех IO-ожиданий. Требуется его оптимизация (проверка плана, индексов, возможно, переписывание).
2. Изменение характера IO
- В инциденте IO стало определяться чтением, а не записью. Это указывает на то, что рабочий набор данных не помещается в shared buffers, либо буферный кэш активно вытесняется.
3. Рост LOCK и LWLOCK
- Хотя их доля мала, рост на 20–25% может сигнализировать о внутренней конкуренции, требующей анализа блокировок.
Проблемы инфраструктуры
1. Дефицит оперативной памяти
- Свободная RAM менее 5% в течение всего инцидента – критический уровень. Это приводит к усилению сбросов dirty страниц и росту физических чтений.
2. Перегрузка CPU
- Очередь процессов на выполнение (r) постоянно превышает количество ядер – система не успевает обрабатывать запросы.
3. Дисковая подсистема – узкое место
- Высокий и растущий уровень процессов в uninterruptible sleep (b), постоянное превышение wa > 10% и корреляция скорости с записью указывают на то, что диски не справляются с нагрузкой.
4. Смена паттерна нагрузки
- Исчезновение корреляций cs–in и cs–us говорит о переходе от CPU-интенсивной работы к I/O-ожиданию, что типично при нехватке памяти и медленных дисках.
Общий вывод:
В инциденте произошло качественное изменение: система перешла от нагрузки, связанной с записью, к нагрузке с преобладанием чтения с диска, вызванному критическим дефицитом свободной памяти.
Дисковая подсистема стала основным тормозом, что подтверждается ростом заблокированных процессов и сохранением сильной связи скорости с записью. Необходима оптимизация проблемного запроса, увеличение доступной памяти (или настройка кэширования) и анализ производительности дисков.
Послесловие
Проведенный анализ позволил не только зафиксировать факт снижения производительности, но и выявить его глубинную причину — критический дефицит оперативной памяти, который изменил характер нагрузки с преимущественно записи на физическое чтение с диска, превратив дискретную подсистему в главное узкое место. Система перешла в режим устойчивого ожидания I/O, что подтверждается ростом заблокированных процессов и сильной обратной связью между скоростью и операциями записи. Полученные результаты служат основой для принятия конкретных мер: оптимизации доминирующего запроса select scenario1(), увеличения доступной памяти или настройки параметров кэширования, а также углубленного анализа производительности дискового массива.