1. Анализ статистических данных производительности СУБД

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

Периоды наблюдения:

• Период 1 (тестовый): 2026-04-10 11:20 – 12:20
• Период 2 (инцидентный): 2026-04-10 12:20 – 13:20

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

• CPU: 16 vCPU (Intel Xeon Skylake, KVM виртуализация)
• RAM: 62.80 GB
• Дисковая подсистема: LVM на виртуальных дисках vdb (данные, 2 ТБ), vdc (WAL, 100 ГБ)

Версия СУБД: PostgreSQL 15.14

Ключевые параметры конфигурации (из предоставленных):

• shared_buffers = 16079 MB (~25% RAM)
• effective_cache_size = 48237 MB (~75% RAM)
• work_mem = 12 MB
• maintenance_work_mem = 1024 MB
• random_page_cost = 1.1 (значение для SSD)
• effective_io_concurrency = 300
• checkpoint_timeout = 15 min
• max_wal_size = 8 GB
• autovacuum_naptime = 1s, autovacuum_max_workers = 8, autovacuum_work_mem = 256 MB
• track_io_timing = on
• Расширения: pg_wait_sampling, pgpro_stats

Уровни достоверности:

• Уровень-1: Подтверждено данными
• Уровень-2: Вероятно, но требует проверки
• Уровень-3: Предположение/недостаточно данных
• Уровень-4: Невозможно оценить

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

Граничные значения операционной скорости (SPEED) и ожиданий СУБД (WAITINGS)

Период 1 (11:20–12:20):

• SPEED:
  MIN: 475 128
  MEDIAN: 987 493
  MAX: 1 258 560
• WAITINGS:
  MIN: 1 590
  MEDIAN: 2 089
  MAX: 3 244

Период 2 (12:20–13:20):

• SPEED:
  MIN: 63 999
  MEDIAN: 241 876
  MAX: 652 229
• WAITINGS:
  MIN: 1 589
  MEDIAN: 2 088
  MAX: 2 826

Наблюдение (Уровень-1):

• Медианное значение SPEED во втором периоде снизилось в 4,1 раза по сравнению с первым (с 987 тыс. до 242 тыс. условных единиц).
• Минимальное значение SPEED во втором периоде упало до 64 тыс. — более чем в 7 раз ниже минимума первого периода.
• Медианное количество ожиданий WAITINGS практически не изменилось (около 2088–2089), однако размах вариации во втором периоде несколько уменьшился (MAX снизился с 3244 до 2826).

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

Период 1:

• SPEED:
  R² тренда: 0.29
  Угол наклона: -28.28
  Качество модели: слабое (объясняет менее 40% вариации)
• WAITINGS:
  R² тренда: 0.39
  Угол наклона: +32.02
  Качество модели: слабое (объясняет менее 40% вариации)

Период 2:

• SPEED:
  R² тренда: 0.85
  Угол наклона: -42.65
  Качество модели: очень высокое (объясняет более 80% дисперсии)
• WAITINGS:
  R² тренда: 0.78
  Угол наклона: +41.37
  Качество модели: хорошее (объясняет от 60% до 80% вариации)

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

1.1. СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД

Корреляция SPEED и WAITINGS:

• Период 1:
  r = -0.0642
  Значимость: незначима (p > 0.05)
  R² = 0.00 (модель непригодна)
• Период 2:
  r = -0.7822
  Значимость: значима (p < 0.05)
  R² = 0.61 (качество модели хорошее)

Интегральный приоритет типов ожиданий:

• В обоих периодах единственный значимый тип ожидания с критическим ВКО = 1.0 — IO.
• ВКО для LWLock < 0.01, игнорируется согласно методологии.
• Регрессия WAITINGS по IO: R² = 1.0, угол наклона 45° (математическая зависимость, так как IO составляет ~100% всех ожиданий).

Вывод (Уровень-1): Во втором периоде проявилась сильная обратная связь между операционной скоростью и общим количеством ожиданий, которые практически полностью состоят из ожиданий IO. Это указывает на то, что падение производительности напрямую связано с ростом IO-ожиданий.

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

• В первом периоде связь SPEED–WAITINGS отсутствовала, тренды слабые.
• Во втором периоде наблюдается резкое падение SPEED, коррелирующее с ростом WAITINGS, причем ожидания IO доминируют.
• Уровень-1: Падение производительности во втором периоде обусловлено увеличением IO-ожиданий.

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

Период 1:

• procs_r:
  R² тренда: 0.58
  Угол наклона: +37.31
  Качество модели: удовлетворительное
  Тренд: рост (ухудшение), сильный, требует внимания
• procs_b:
  R² тренда: 0.00
  Угол наклона: 0.00
  Качество модели: неудовлетворительное
  Тренд: отсутствует (шум)
• cpu_wa:
  R² тренда: 0.61
  Угол наклона: +37.96
  Качество модели: хорошее
  Тренд: рост (ухудшение), сильный
• cpu_id:
  R² тренда: 0.89
  Угол наклона: -43.37
  Качество модели: очень высокое
  Тренд: снижение (ухудшение), критичный

Период 2:

• procs_r:
  R² тренда: 0.41
  Угол наклона: -32.67
  Качество модели: удовлетворительное
  Тренд: снижение (улучшение), незначимый
• procs_b:
  R² тренда: 0.53
  Угол наклона: +36.07
  Качество модели: удовлетворительное
  Тренд: рост (ухудшение), умеренный
• cpu_wa:
  R² тренда: 0.20
  Угол наклона: +24.24
  Качество модели: слабое
  Тренд: рост (ухудшение), шум, незначимый
• cpu_id:
  R² тренда: 0.37
  Угол наклона: +31.41
  Качество модели: слабое
  Тренд: рост (улучшение), незначимый

Интерпретация (Уровень-1):

• В первом периоде наблюдался выраженный тренд снижения cpu_id (R²=0.89) и роста cpu_wa (R²=0.61), что указывает на нарастание проблем с ожиданием IO к концу периода.
• Во втором периоде тренды менее выражены, но сохраняется рост процессов в непрерываемом сне (procs_b). cpu_wa стабильно низок (медиана 2%), cpu_id высок (медиана 88%).

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

• Период 1 характеризовался прогрессирующим снижением свободного CPU и ростом IO-wait, что коррелирует с данными по ожиданиям IO внутри СУБД.
• Период 2 демонстрирует стабильно высокий idle CPU и низкий IO-wait, несмотря на резкое падение операционной скорости СУБД. Противоречие: падение производительности БД не отражается в метриках CPU ОС (idle высок). (Уровень-1)

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

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

• Оба периода: свободная RAM <5% в 100% времени (ALARM). (Уровень-1)
• Остальные показатели в норме (r, sy, wa, b, swap) — OK. (Уровень-1)

Корреляции IO с метриками vmstat (только значимые):

Период 1:

• IO ↔ bi (чтение):
  r = 0.763
  R² = 0.58 (качество модели удовлетворительное)
  Уровень-1
• IO ↔ bo (запись):
  r = 0.794
  R² = 0.63 (качество модели хорошее)
  Уровень-1
• IO ↔ wa (IO wait):
  r = 0.602
  R² = 0.36 (качество модели слабое)
  Уровень-1

Период 2:

• IO ↔ bi (чтение):
  r = 0.759
  R² = 0.58 (качество модели удовлетворительное)
  Уровень-1
• IO ↔ bo (запись): отсутствует (незначима). Уровень-1
• IO ↔ wa (IO wait):
  r = 0.630
  R² = 0.40 (качество модели удовлетворительное)
  Уровень-1

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

Период 1:

• cs ↔ in (прерывания):
  r = 0.928
  R² = 0.86 (качество модели очень высокое)
  Уровень-1
• cs ↔ us (user time):
  r = 0.866
  R² = 0.75 (качество модели хорошее)
  Уровень-1
• cs ↔ sy (system time):
  r = 0.970
  R² = 0.94 (качество модели очень высокое)
  Уровень-1

Период 2:

• cs ↔ in (прерывания):
  r = 0.404 (слабая)
  R²: модель непригодна
  Уровень-1
• cs ↔ us (user time):
  r = 0.785
  R² = 0.62 (качество модели хорошее)
  Уровень-1
• cs ↔ sy (system time):
  r = 0.896
  R² = 0.80 (качество модели очень высокое)
  Уровень-1

Интерпретация:

• В обоих периодах ожидания IO сильно коррелируют с чтением (bi), а в первом периоде также с записью (bo). Во втором периоде корреляция с записью пропала, что может указывать на изменение характера нагрузки.
• Переключения контекста (cs) в обоих периодах очень сильно коррелируют с sy (system time), что характерно для интенсивного взаимодействия с ядром (возможно, из-за частых системных вызовов или блокировок). В первом периоде также высока корреляция с прерываниями и user time, во втором — только с user и sy.
• Уровень-2 (вероятно): Высокая корреляция cs и sy может быть признаком активного ожидания на спин-блокировках или частых системных вызовов, но без данных профилирования (perf) подтвердить невозможно.

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

• Ожидания IO в СУБД в обоих периодах связаны преимущественно с операциями чтения с диска.
• Во втором периоде связь с записью исчезла, что может указывать на изменение профиля нагрузки (больше чтений, меньше записей).
• Системное время (sy) и переключения контекста (cs) тесно связаны; это может быть следствием высокой конкуренции за ресурсы на уровне ОС или внутри СУБД (например, частые блокировки).

1.4. ДИАГРАММЫ ПАРЕТО ПО WAIT_EVENT_TYPE и QUERYID

WAIT_EVENT (детализация по событиям IO):

Период 1:

• BufFileRead:
  COUNT: 129 801
  % от всех IO: 53.87%
  Примечание: чтение временных файлов (Уровень-1)
• DataFileRead:
  COUNT: 110 964
  % от всех IO: 46.05%
  Примечание: чтение файлов данных (Уровень-1)

Период 2:

• DataFileRead:
  COUNT: 171 815
  % от всех IO: 99.86%
  Примечание: доминирует чтение данных (Уровень-1)

QUERYID (топ-запрос по ожиданиям IO):

Период 1:

• QUERYID: 8811732978066195686
• CALLS: 1 915
• WAITINGS: 236 314
• % от IO: 98.07%
• WAIT_EVENT LIST: BufFileWrite, DataFilePrefetch, DataFileExtend, DataFileRead, BufFileRead

Период 2:

• QUERYID: 8811732978066195686
• CALLS: 793
• WAITINGS: 164 394
• % от IO: 95.55%
• WAIT_EVENT LIST: DataFilePrefetch, DataFileExtend, DataFileRead

Вывод (Уровень-1):

• Во втором периоде резко изменился состав ожиданий: практически все ожидания IO приходятся на DataFileRead (чтение таблиц/индексов), в то время как в первом периоде значительную долю составляло чтение временных файлов (BufFileRead).
• Один и тот же запрос (QUERYID=8811732978066195686) доминирует по ожиданиям IO в обоих периодах, но во втором периоде количество вызовов снизилось с 1915 до 793, при этом доля ожиданий от всех IO осталась высокой (95.55%). Это указывает на то, что стоимость одного выполнения запроса выросла. (Уровень-1)
• Во втором периоде в списке событий ожидания этого запроса отсутствует BufFileWrite и BufFileRead, что говорит о прекращении использования временных файлов (возможно, изменился план выполнения или параметры запроса). (Уровень-2)

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

• Основной источник проблем — один конкретный запрос, который во втором периоде стал выполняться значительно медленнее из-за интенсивного чтения данных с диска (DataFileRead), вероятно, вследствие изменения плана выполнения или увеличения объёма обрабатываемых данных.
• Отсутствие ожиданий на временных файлах во втором периоде может быть как положительным признаком (уменьшение использования temp), так и отрицательным (например, запрос перестал помещаться в work_mem и ушёл в однопроходное чтение с диска без буферизации).

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

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

• Оба периода: IO составляет ~100% всех ожиданий. LWLock присутствует в незначительном количестве (медиана 1), ВКО <0.01. (Уровень-1)
• Противоречие: Несмотря на низкий cpu_wa (медиана 2–3%) и высокий cpu_id, СУБД испытывает критические ожидания IO. (Уровень-1)
• Гипотеза (Уровень-2): Ожидания IO внутри PostgreSQL могут быть связаны не с физическим диском, а с ожиданиями на файловых дескрипторах или сетевыми задержками (но в данных только локальный диск). Более вероятно — неэффективные операции чтения с высокой латентностью на уровне виртуализации, не отражаемые в cpu_wa гостевой ОС.

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

• shared_buffers = 16 GB (25% RAM) — соответствует рекомендациям для систем с большим объёмом памяти. (Уровень-1)
• effective_cache_size = 48 GB — адекватно объёму RAM. (Уровень-1)
• work_mem = 12 MB — относительно небольшое значение. Может приводить к использованию временных файлов при сортировках и хешах. (Уровень-1)
• Свободная память (memory_free) постоянно менее 5% (ALARM), но это не обязательно проблема, так как память активно используется под кэш ОС (memory_cache около 54 GB). (Уровень-1)
• Уровень-2: Низкая свободная память сама по себе не является проблемой при отсутствии свопинга (swap_si/so = 0). Однако в сочетании с низким work_mem может указывать на то, что СУБД недостаточно использует память для операций, полагаясь на дисковые временные файлы.

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

• Устройство данных (vdb):
  Период 1: медианная загрузка (%util) 36%, максимум 53%
  Период 2: медианная загрузка 29.17%, максимум 49%
• Средняя длина очереди (aqu_sz) >1 в течение 83.6% времени в первом периоде и 100% во втором (ALARM). (Уровень-1)
• Латентность чтения (r_await) <1.1 мс, записи (w_await) <4.1 мс — очень низкая, характерна для SSD. (Уровень-1)
• Устройство WAL (vdc): загрузка <6%, латентность записи <1 мс. (Уровень-1)
• Противоречие (Уровень-1): При низкой латентности и умеренной загрузке диска наблюдается высокая очередь запросов (>1), что может указывать на неравномерность нагрузки (bursts) или ограничения на уровне гипервизора. Также высокая очередь может быть артефактом виртуализованного устройства.
• Уровень-2: Вероятно, дисковая подсистема не является узким местом с точки зрения пропускной способности или IOPS, но задержки на уровне виртуализации (KVM) могут вызывать увеличение времени отклика для отдельных операций, что приводит к накоплению очереди.

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

• В обоих периодах cpu_us + cpu_sy <12%, cpu_id >85%. (Уровень-1)
• Частота переключений контекста (cs) медианная:
  Период 1: 8556 в секунду (~535 на ядро)
  Период 2: 7499 в секунду (~469 на ядро)
  Значения не являются аномально высокими. (Уровень-1)
• Уровень-2: Высокая корреляция cs с sy (R²=0.94 в первом периоде, 0.80 во втором) может указывать на значительные накладные расходы ядра при обработке системных вызовов. При низкой общей загрузке CPU это не критично, но может сигнализировать о неоптимальной работе приложения (частые короткие запросы, отсутствие пула соединений).

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

• LWLock ожидания присутствуют в минимальном количестве (медиана 1), корреляция с WAITINGS незначима (ВКО <0.01). (Уровень-1)
• Lock ожидания отсутствуют полностью. (Уровень-1)
• Уровень-1: Блокировки не являются источником проблем.

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

• Запрос 8811732978066195686 — основной потребитель ресурсов IO.
• Во втором периоде количество вызовов сократилось на 58%, но ожидания IO остались на высоком уровне (164k против 236k), что означает рост ожиданий на один вызов примерно в 2.6 раза. (Уровень-1)
• Уровень-3: Точная причина роста стоимости запроса неизвестна. Требуется анализ плана выполнения (EXPLAIN ANALYZE) за оба периода и статистики по таблицам (pg_stat_user_tables). Возможно изменение данных (увеличение объёма), изменение плана запроса из-за обновления статистики или изменение параметров (например, work_mem или enable_*).

2. Анализ IO

Список дисковых устройств

• vdb — данные (/data), LVM datavg-data, 2 ТБ.
• vdc — WAL (/wal), LVM walvg-wal, 100 ГБ.

Граничные значения по дисковым устройствам (медианы)

Устройство vdb:

• Период 1:
  r/s: 1342
  rMB/s: 43.3
  w/s: 88.1
  wMB/s: 1.58
  r_await: 1.02 мс
  w_await: 3.78 мс
  %util: 36.0%
  aqu_sz: 2.04
• Период 2:
  r/s: 1260
  rMB/s: 41.3
  w/s: 67.4
  wMB/s: 1.07
  r_await: 1.01 мс
  w_await: 3.86 мс
  %util: 29.2%
  aqu_sz: 1.76

Устройство vdc:

• Период 1:
  r/s: 0
  rMB/s: 0
  w/s: 18.4
  wMB/s: 0.78
  r_await: –
  w_await: 0.93 мс
  %util: 5.07%
  aqu_sz: 0.02
• Период 2:
  r/s: 0
  rMB/s: 0
  w/s: 15.6
  wMB/s: 0.57
  r_await: –
  w_await: 0.90 мс
  %util: 4.27%
  aqu_sz: 0.02

Наблюдения (Уровень-1):

• Чтение с vdb доминирует по объёму (~40–43 MB/s), запись незначительна (~1–1.5 MB/s).
• Запись на vdc (WAL) также невысокая (<1 MB/s).
• Латентность на обоих устройствах отличная (<2 мс на чтение, <4 мс на запись).
• Очередь запросов на vdb постоянно >1, что при низкой загрузке может указывать на ограничения параллелизма в гипервизоре или особенности планировщика ввода-вывода гостевой ОС.

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

• %util > 50%: 13.1% времени в П1, 0% в П2 (OK).
• r_await / w_await > 5ms: 0% (OK).
• aqu_sz > 1: 83.6% времени в П1, 100% в П2 (ALARM).

Противоречие (Уровень-1): Устройство не перегружено по пропускной способности и IOPS, но очередь запросов стабильно высокая. Возможные причины:

• Всплески запросов, не улавливаемые минутным усреднением iostat.
• Виртуализация: гипервизор может лимитировать количество одновременных операций ввода-вывода, что приводит к образованию очереди в гостевой ОС.
• Настройки effective_io_concurrency = 300 могут быть слишком высокими для реальных возможностей хранилища, вызывая излишнее распараллеливание и очереди. (Уровень-2)

2.1. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ "КОРРЕЛЯЦИЯ VMSTAT и IOSTAT" по дисковым устройствам

2.1.1 КОРРЕЛЯЦИЯ VMSTAT и IOSTAT

vmstat/wa ↔ iostat/%util:

• Период 1, устройство vdb:
  r = 0.796
  R² = 0.63 (качество модели хорошее)
  Уровень-1
• Период 1, устройство vdc:
  r = 0.500
  R² = 0.25 (качество модели слабое)
  Уровень-1
• Период 2, устройство vdb:
  r = 0.856
  R² = 0.73 (качество модели хорошее)
  Уровень-1
• Период 2, устройство vdc:
  r = 0.339 (модель непригодна)
  Уровень-1

Вывод: На устройстве данных vdb в обоих периодах прослеживается сильная связь между ожиданиями IO на уровне ОС и утилизацией устройства. Это подтверждает, что cpu_wa адекватно отражает загрузку диска, но абсолютные значения низкие.

Итог по 1.1 КОРРЕЛЯЦИЯ VMSTAT и IOSTAT

• Ожидания IO в ОС (wa) предсказуемо связаны с загрузкой устройства vdb.
• Связь на vdc слабая из-за низкой нагрузки.

2.1.2 БУФЕРИЗАЦИЯ ВВОДА-ВЫВОДА

Во всех периодах и для обоих устройств корреляции memory_buff с операциями ввода-вывода отсутствуют (незначимы или слабые). (Уровень-1)

Итог по 1.2 БУФЕРИЗАЦИЯ ВВОДА-ВЫВОДА

• Буферный кэш файловой системы не оказывает значимого влияния на динамику ввода-вывода в рамках данных периодов.

2.1.3 КЭШИРОВАНИЕ ВВОДА-ВЫВОДА

Корреляция cache ↔ rMBps:

• Период 1, устройство vdb: незначима. Уровень-1
• Период 2, устройство vdb:
  r = 0.901 (значима)
  R² = 0.81 (качество модели очень высокое)
  Уровень-1

Интерпретация (Уровень-1): Во втором периоде появилась очень сильная прямая связь между объёмом кэша ОС (memory_cache) и скоростью чтения с диска (rMBps). Это нетипично: обычно увеличение кэша должно снижать потребность в чтении с диска. Здесь же рост кэша сопровождается ростом чтений.
Гипотеза (Уровень-2): Возможно, кэш ОС активно пополняется данными, которые читаются СУБД (эффект "холодного" кэша при последовательном сканировании большой таблицы). То есть большой объём чтения приводит к росту кэша, а не наоборот. Модель с R²=0.81 подтверждает сильную зависимость.

Итог по 1.3 КЭШИРОВАНИЕ ВВОДА-ВЫВОДА

• Во втором периоде наблюдается аномальная корреляция кэша и чтения, что может быть признаком интенсивного последовательного чтения больших объёмов данных (seq scan).

2.1.4 КОРРЕЛЯЦИЯ ОПЕРАЦИОННОЙ СКОРОСТИ И МЕТРИК ПРОИЗВОДИТЕЛЬНОСТИ ДИСКОВОГО УСТРОЙСТВА

Период 1, устройство vdb:

• SPEED ↔ IOPS:
  r = -0.710
  R² = 0.50 (качество модели удовлетворительное)
  Вывод: умеренная обратная связь с IOPS, но не с MBps. (Уровень-1)
• SPEED ↔ MBps: незначима.

Период 1, устройство vdc:

• SPEED ↔ IOPS: r = -0.450, R² = 0.20 (слабая связь). Уровень-1
• SPEED ↔ MBps: незначима.

Период 2, устройство vdb:

• SPEED ↔ IOPS: незначима.
• SPEED ↔ MBps:
  r = 0.894
  R² = 0.80 (качество модели очень высокое)
  Вывод: очень сильная прямая связь с MBps. (Уровень-1)

Период 2, устройство vdc:

• Все корреляции незначимы.

Ключевое изменение (Уровень-1):

• В первом периоде операционная скорость была умеренно обратно связана с IOPS (больше операций ввода-вывода → ниже скорость). Это логично для нагрузки, чувствительной к задержкам отдельных операций.
• Во втором периоде связь с IOPS пропала, но появилась очень сильная прямая связь с пропускной способностью (MBps). То есть при росте объёма читаемых данных операционная скорость растёт. Это парадоксально, так как обычно интенсивное чтение должно снижать производительность.

Разрешение противоречия (Уровень-2):
Операционная скорость (SPEED) рассчитывается как сумма запросов + строк. Если запрос начинает возвращать/обрабатывать значительно больше строк (например, из-за изменения плана на seq scan с фильтрацией на стороне СУБД), то SPEED может расти даже при ухудшении времени отклика. Таким образом, высокая корреляция SPEED с MBps во втором периоде может быть артефактом расчёта метрики: рост объёма читаемых данных приводит к росту количества обработанных строк, что увеличивает SPEED, несмотря на падение пропускной способности по запросам.
Уровень-3: Для подтверждения необходимы данные о количестве выполненных запросов и возвращённых строк отдельно, а также планы выполнения.

Итог по 1.4 КОРРЕЛЯЦИЯ ОПЕРАЦИОННОЙ СКОРОСТИ И МЕТРИК ПРОИЗВОДИТЕЛЬНОСТИ ДИСКОВОГО УСТРОЙСТВА

• Изменение характера корреляции указывает на смену профиля нагрузки: с чувствительной к IOPS на чувствительную к пропускной способности (возможно, переход на последовательное сканирование).

ИНДЕКС ПРИОРИТЕТА КОРРЕЛЯЦИИ (CPI)

• Период 1, наивысший CPI: wa ↔ util (vdb) = 0.794.
• Период 2, лидируют:
  cache ↔ rMBps (vdb) = 0.900
  SPEED ↔ MBps (vdb) = 0.844

Итог по разделу "СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ "КОРРЕЛЯЦИЯ VMSTAT и IOSTAT" по дисковым устройствам"

• Дисковое устройство данных vdb является основным источником ввода-вывода. Его производительность (латентность, пропускная способность) не является узким местом в классическом понимании, но во втором периоде наблюдается аномальное поведение: рост кэша коррелирует с ростом чтения, а операционная скорость — с пропускной способностью. Это косвенно подтверждает гипотезу о включении последовательного сканирования больших таблиц.

Проблемы инфраструктуры по итогам сравнительного анализа

Согласно протоколу проверки из инструкции pg_expecto 1.1:

Silent error swallowing:

• Уровень-4: Логи PostgreSQL не предоставлены. Невозможно проверить наличие предупреждений (checkpoint too frequent, temp file size exceeds и т.п.).

Resource leaks:

• Соединения: Данных о numbackends нет. Уровень-4.
• Временные файлы: Статистика по temp_files отсутствует, но в первом периоде зафиксированы ожидания BufFileRead и BufFileWrite (53.87% от всех IO). Во втором периоде они исчезли. Это может указывать либо на уменьшение использования временных файлов, либо на изменение плана запроса, который перестал их создавать. Уровень-2: Необходима статистика pg_stat_database.temp_files за оба периода.
• Использование памяти процессом: Данных нет. Уровень-4.
• Подготовленные транзакции: Данных нет. Уровень-4.

Copy-paste without understanding (неадекватные параметры):

• random_page_cost = 1.1 — корректно для SSD (подтверждено латентностью <1 мс). Уровень-1.
• effective_io_concurrency = 300 — высокое значение, может быть избыточным, но для SSD допустимо. Уровень-2: Рекомендуется проверить фактическую эффективность (например, через pg_stat_statements и track_io_timing).
• work_mem = 12 MB — относительно низкое. Учитывая наличие ожиданий BufFileRead в первом периоде, возможно, увеличение помогло бы снизить использование временных файлов. Уровень-2.
• autovacuum_naptime = 1s, autovacuum_vacuum_scale_factor = 0.01 — агрессивные настройки autovacuum, что хорошо для активно обновляемых таблиц. Без статистики по таблицам оценить эффективность невозможно. Уровень-3.
• checkpoint_timeout = 15min, max_wal_size = 8GB — параметры контрольных точек сбалансированы. Данных о частоте контрольных точек нет. Уровень-3.

Race conditions:

• Частота переключений контекста (cs) не является экстремально высокой (~500 на ядро в сек). Высокая корреляция с sy при низкой общей загрузке CPU может указывать на неэффективное использование системных вызовов, но не на гонки. Уровень-2: Рекомендуется профилирование приложения и анализ pg_stat_statements на предмет большого количества очень быстрых запросов.

Противоречие "низкий cpu_wa — высокие ожидания IO в СУБД":

• Уровень-1: Факт противоречия зафиксирован.
• Иерархия доверия: данные СУБД (pg_wait_sampling) имеют приоритет над vmstat. Следовательно, проблема с ожиданиями IO реальна для процессов PostgreSQL.
• Гипотезы (Уровень-2):
  Ожидания IO в PostgreSQL могут включать не только физический диск, но и ожидания освобождения буферов, связанные с work_mem и временными файлами.
  Виртуализация: гипервизор может задерживать отдельные операции ввода-вывода, не отражая это в %iowait гостевой ОС.
• Необходимые данные (Уровень-3): iostat -x 1 в моменты пиковых ожиданий, данные трассировки системных вызовов (strace), анализ событий ожидания DataFileRead с привязкой к конкретным файлам и смещениям.

3. Итог

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

1. Резкое падение операционной скорости во втором периоде (медиана снизилась в 4 раза) с одновременным ростом ожиданий IO типа DataFileRead. (Уровень-1)
2. Один запрос (QUERYID=8811732978066195686) является доминирующим потребителем IO в обоих периодах. Во втором периоде стоимость его выполнения значительно возросла. (Уровень-1)
3. Изменение профиля ожиданий: переход от смешанных BufFileRead/DataFileRead к почти исключительно DataFileRead. (Уровень-1)
4. Аномальная корреляция во втором периоде: SPEED положительно связан с пропускной способностью чтения, а memory_cache — с объёмом чтения. (Уровень-1)
5. Постоянно высокая очередь запросов к диску данных при низкой утилизации и отличной латентности. (Уровень-1)

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

• Неоптимальный план выполнения проблемного запроса во втором периоде. Вероятно, переход на последовательное сканирование большой таблицы вместо использования индекса или эффективной работы с временными файлами. (Уровень-2)
• Возможное влияние низкого work_mem (12 MB), что могло приводить к использованию временных файлов в первом периоде, а во втором — к выбору плана с seq scan. (Уровень-2)
• Отсутствие актуальной статистики по таблицам? (Уровень-3) Требуется проверка pg_stat_user_tables.last_analyze.

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

• Высокая очередь запросов к vdb при низкой утилизации может указывать на ограничения виртуализованного хранилища (лимиты IOPS на уровне гипервизора). (Уровень-2)
• Свободная память <5% — не критично при отсутствии свопинга, но требует мониторинга. (Уровень-1)
• Высокая корреляция cs с sy — возможная неэффективность на уровне приложения (частые короткие запросы). (Уровень-2)

4. Общие рекомендации по оптимизации производительности СУБД и инфраструктуры

Примечание: Рекомендации даются в соответствии с правилами инструкции: без конкретных предложений по изменению параметров, если уверенности недостаточно. Предлагаются направления для дальнейшей диагностики.

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

1. Анализ запроса QUERYID=8811732978066195686 (Уровень-3 → требуется действие):
   Получить текст запроса и планы выполнения (EXPLAIN (ANALYZE, BUFFERS, TIMING)) за оба периода.
   Проверить статистику по таблицам, участвующим в запросе (pg_stats, pg_class.reltuples).
   Оценить адекватность work_mem для данного запроса. При необходимости протестировать увеличение до 64–128 MB на уровне сессии.
2. Проверка использования временных файлов (Уровень-2):
   Собрать метрики temp_files и temp_bytes из pg_stat_database за оба периода.
   Если в первом периоде использование временных файлов было значительным, рассмотреть увеличение work_mem глобально или для конкретных ролей/баз.
3. Анализ эффективности кэширования (Уровень-2):
   Проверить pg_statio_user_tables.heap_blks_read vs heap_blks_hit для таблиц, задействованных в проблемном запросе. Низкий hit ratio укажет на недостаток shared_buffers или неэффективный план.
4. Мониторинг планов запросов (Уровень-2):
   Включить auto_explain с параметрами log_min_duration и log_analyze для фиксации планов медленных запросов.

4.2 Конкретные рекомендации по оптимизации инфраструктуры

1. Дисковая подсистема (Уровень-2):
   Проверить настройки планировщика ввода-вывода в гостевой ОС (например, mq-deadline или none для виртуализованных SSD).
   Оценить возможность снижения effective_io_concurrency до 100–200, так как текущее значение 300 может создавать излишнюю очередь при отсутствии реального параллелизма на стороне хранилища.
2. Виртуализация (Уровень-2):
   Проверить наличие ограничений IOPS на уровне гипервизора для виртуальных дисков vdb и vdc.
   Сравнить латентность, видимую гостевой ОС, с фактической латентностью на хостовой системе (если есть доступ).
3. Сетевая подсистема (Уровень-3):
   Данных о сетевой активности нет. Если клиенты подключаются удалённо, рекомендуется проверить задержки и возможные потери пакетов.

5. Заключение

Сравнительный анализ выявил существенное ухудшение производительности PostgreSQL во втором периоде (12:20–13:20), связанное с резким ростом ожиданий ввода-вывода на чтение данных (DataFileRead). Основной вклад вносит один запрос, план выполнения которого, вероятно, изменился, что привело к увеличению объёма читаемых с диска данных. Дисковая подсистема демонстрирует хорошие показатели латентности и пропускной способности, но наблюдаются признаки ограничений на уровне виртуализации (высокая очередь при низкой утилизации). Критически не хватает данных о планах запросов, статистике по таблицам и использовании временных файлов для точной диагностики. Рекомендовано провести углублённый анализ проблемного запроса и пересмотреть параметры work_mem и effective_io_concurrency.

Уровень-1 (подтверждённые выводы): Падение операционной скорости, доминирование DataFileRead ожиданий, высокая очередь к диску данных.
Уровень-2 (вероятные причины): Изменение плана запроса на seq scan, влияние низкого work_mem, ограничения виртуализации.
Уровень-3 (необходимые дополнительные данные): Планы выполнения запроса, статистика pg_stat_user_tables, метрики временных файлов, данные о частоте контрольных точек.