Общая информация
Периоды анализа:
· Период 1 (тестовый): 2026-04-07 13:02 – 14:02
· Период 2 (инцидентный): 2026-04-07 14:02 – 15:02
Конфигурация сервера:
· CPU: 16 виртуальных ядер (Intel Xeon Skylake, KVM)
· RAM: 62.80 ГБ
· ОС: AstraLinux SE (ядро Linux)
· PostgreSQL 15.14
· Данные на LVM-томах:
o /data на устройстве vdb (2 ТБ)
o /wal на устройстве vdc (100 ГБ)
o /log на устройстве vdd (20 ГБ)
o /backup на устройствах vde+vdf (2.5 ТБ)
Ключевые настройки PostgreSQL:
· shared_buffers = 16079 МБ
· effective_cache_size = 48237 МБ
· maintenance_work_mem = 1024 МБ
· work_mem = 12 МБ
· max_wal_size = 8 ГБ
· checkpoint_timeout = 15 мин
· autovacuum_naptime = 1 сек, scale factor для vacuum = 0.01, analyze = 0.005
· wal_compression = on
· effective_io_concurrency = 300
· random_page_cost = 1.1
Методология анализа: Использована трёхэтапная статистическая методика для ожиданий (p-value, ВКО, R²) и двухэтапная для метрик (p-value, R²). Корреляции с p-value ≥ 0.05 исключены из интерпретации. R² < 0.2 рассматривается как непригодная модель.
1. Общий анализ операционной скорости и ожиданий СУБД
Граничные значения операционной скорости (SPEED) и ожиданий СУБД (WAITINGS)
· SPEED, минимальное значение
o Период 1: 275 406
o Период 2: 477 877
o Изменение: +73.5%
· SPEED, медиана
o Период 1: 413 435
o Период 2: 964 880
o Изменение: +133.4%
· SPEED, максимальное значение
o Период 1: 967 615
o Период 2: 1 201 209
o Изменение: +24.1%
· WAITINGS, минимальное значение
o Период 1: 2 232
o Период 2: 2 035
o Изменение: -8.8%
· WAITINGS, медиана
o Период 1: 2 510
o Период 2: 2 536
o Изменение: +1.0%
· WAITINGS, максимальное значение
o Период 1: 3 069
o Период 2: 3 561
o Изменение: +16.0%
Наблюдения:
· В периоде 2 медианная операционная скорость выросла более чем вдвое, при этом минимальное значение увеличилось на 73.5%, что может указывать на разное соотношение полезной работы и ожиданий.
· Медианное количество ожиданий практически не изменилось, но максимальное возросло на 16%.
· В обоих периодах ожидания типа IO составляют >99.9% всех ожиданий (см. x.1.test.postgresql.cluster_performance.txt и x.postgresql.cluster_performance.txt).
Анализ трендов операционной скорости (SPEED) и ожиданий СУБД (WAITINGS)
· SPEED, коэффициент детерминации R²
o Период 1: 0.4300 (удовлетворительное качество модели)
o Период 2: 0.3200 (слабое качество модели)
· SPEED, угол наклона
o Период 1: +33.14 (рост)
o Период 2: -29.61 (падение)
· WAITINGS, коэффициент детерминации R²
o Период 1: 0.5500 (удовлетворительное)
o Период 2: 0.4700 (удовлетворительное)
· WAITINGS, угол наклона
o Период 1: +36.63 (рост)
o Период 2: +34.57 (рост)
· Регрессия SPEED ~ WAITINGS, R²
o Период 1: 0.1100 (непригодная модель)
o Период 2: 0.5200 (удовлетворительное качество)
· Корреляция SPEED ~ WAITINGS
o Период 1: отсутствует или положительная (статистически незначима)
o Период 2: -0.7192 (p<0.05, значимая обратная связь)
Выводы:
· В периоде 1 тренд операционной скорости положительный, модель удовлетворительная (R²=0.43). В периоде 2 модель слабая (R²=0.32) и тренд отрицательный, что указывает на снижение производительности во времени.
· Ожидания растут в обоих периодах (положительный угол наклона), модели удовлетворительные.
· В периоде 1 связь между скоростью и ожиданиями статистически незначима (R²=0.11). В периоде 2 появляется значимая обратная корреляция (r=-0.7192), модель объясняет 52% вариации: рост ожиданий сопровождается снижением скорости.
1.1. СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД
Период 1:
· Единственный значимый тип ожидания: IO.
· Корреляция IO с общими ожиданиями: 1.0000 (p < 0.05, значима).
· ВКО = 1.0000 (критическое значение).
· R² регрессии ожиданий СУБД по IO = 1.0000 (очень высокое качество).
· Другие типы ожиданий (BufferPin, Extension, IPC, Lock, LWLock, Timeout) имеют отрицательную или отсутствующую корреляцию, статистически незначимы.
· Интегральный приоритет IO = 0.3718.
Период 2:
· Значимые типы: IO и LWLock.
· IO:
o Корреляция с общими ожиданиями: 1.0000 (p < 0.05).
o ВКО = 1.0000 (критическое значение).
o R² = 1.0000 (очень высокое качество).
· LWLock:
o Корреляция: 0.7026 (p < 0.05, значима).
o ВКО = 0.0000 (<0.01, игнорируется в текущем анализе согласно методике).
· Интегральный приоритет IO = 0.6271 (выше, чем в периоде 1).
Итог по разделу "1. СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД"
· В обоих периодах доминируют ожидания ввода-вывода (IO), они объясняют практически всю дисперсию общих ожиданий. Рост интегрального приоритета IO в периоде 2 (с 0.3718 до 0.6271) указывает на усиление влияния дисковой подсистемы на производительность.
· Во втором периоде появляется слабая, но значимая корреляция LWLock с общими ожиданиями (r=0.7026), однако ВКО равен нулю, что в соответствии с методикой не требует немедленного анализа. Природа этой корреляции требует дополнительного изучения (см. раздел «Блокировки и ожидания LWLock»).
1.2. ТРЕНДОВЫЙ АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ vmstat
Сводка по ключевым показателям vmstat:
· procs → r
o Период 1: R² = 0.0000 (нет тренда), значение тренда 0
o Период 2: R² = 0.0000 (нет тренда), значение тренда 0
· procs → b
o Период 1: R² = 0.0000 (нет тренда), значение тренда 0
o Период 2: R² = 0.0000 (нет тренда), значение тренда 0
· cpu → wa
o Период 1: R² = 0.0400 (непригодная модель), негативный тренд, коэффициент тренда 0.4100 (шум)
o Период 2: R² = 0.1400 (непригодная модель), негативный тренд, коэффициент тренда 2.8800 (шум)
· cpu → id
o Период 1: R² = 0.6200 (хорошее качество), негативный тренд, коэффициент тренда 23.7700 (сильный тренд)
o Период 2: R² = 0.2300 (слабое качество), негативный тренд, коэффициент тренда 6.0600 (слабый тренд)
Интерпретация:
· procs → r и procs → b стабильны (медиана 3 и 1 соответственно) и не показывают значимых трендов в обоих периодах.
· cpu → wa (ожидание IO) имеет слабые и непригодные модели тренда, но отрицательный наклон указывает на небольшое увеличение ожиданий IO во времени. Изменения находятся в пределах шума.
· cpu → id (простой CPU) показывает сильный негативный тренд в периоде 1 (R²=0.62, коэф. тренда 23.77), что свидетельствует о существенном снижении простоя CPU в течение часа. В периоде 2 тренд слабый (R²=0.23), но также негативный.
Итог по разделу "2. ТРЕНДОВЫЙ АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ vmstat"
· В периоде 1 наблюдается выраженное снижение простоя CPU (id), что может быть связано с ростом операционной скорости и увеличением полезной работы.
· В периоде 2 тренд снижения простоя CPU слабее, при этом тренд операционной скорости стал отрицательным, что может указывать на достижение предела производительности CPU или переключение ресурсов на обслуживание ожиданий IO.
1.3. СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД и МЕТРИК vmstat
Сводка относительных показателей vmstat (доля периода наблюдения):
· us+sy > 80%:
o Период 1: 0%
o Период 2: 0%
· r > ядер CPU:
o Период 1: 0%
o Период 2: 0%
· sy > 30%:
o Период 1: 0%
o Период 2: 0%
· free RAM < 5%:
o Период 1: 100%
o Период 2: 100%
· swap in / swap out:
o Период 1: 0% / 0%
o Период 2: 0% / 0%
· wa > 10%:
o Период 1: 0%
o Период 2: 0%
· b > ядер CPU:
o Период 1: 0%
o Период 2: 0%
Корреляции между ожиданиями IO и метриками vmstat:
· IO ↔ bi (чтение с диска)
o Период 1: r = 0.7620 (p<0.05), R² = 0.5800
o Период 2: r = 0.5263 (p<0.05), R² = 0.2800
· IO ↔ bo (запись на диск)
o Период 1: r = 0.4482 (p<0.05), R² = 0.2000
o Период 2: r = 0.7332 (p<0.05), R² = 0.5400
· IO ↔ wa (ожидание IO CPU)
o Период 1: r = 0.2291 (незначима)
o Период 2: r = 0.4232 (p<0.05), R² непригодная
Анализ метрик vmstat (корреляции):
· cs ↔ in (переключения контекста ↔ прерывания)
o Период 1: r = 0.8415, R² = 0.7100
o Период 2: r = 0.9311, R² = 0.8700
· cs ↔ sy (system time)
o Период 1: r = 0.2452 (незначима)
o Период 2: данные отсутствуют
· cs ↔ us (user time)
o Период 1: данные отсутствуют
o Период 2: r = 0.7890, R² = 0.6200
Индекс приоритета корреляции (CPI):
Период 1:
· Ранг 1: cs ↔ in, CPI = 0.8422
· Ранг 2: IO ↔ bi, CPI = 0.7147
· Ранг 3: IO ↔ bo, CPI = 0.0000
Период 2:
· Ранг 1: cs ↔ in, CPI = 0.9322
· Ранг 2: cs ↔ us, CPI = 0.6969
· Ранг 3: IO ↔ bo, CPI = 0.6048
· Ранг 4: IO ↔ bi, CPI = 0.0000
Итог по разделу "3. СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД и МЕТРИК vmstat"
· В обоих периодах свободная RAM находится ниже 5% на протяжении 100% времени, однако свопинг отсутствует, что указывает на полное использование памяти под кэш страниц и буферы. shared_buffers (16 ГБ) и effective_cache_size (48 ГБ) согласуются с общим объёмом RAM 62.8 ГБ.
· В периоде 1 доминирует корреляция ожиданий IO с чтением (bi), модель удовлетворительная (R²=0.58). В периоде 2 основной вклад в ожидания IO вносит запись (bo) с очень высокой корреляцией (r=0.7332, R²=0.54), а корреляция с чтением снижается.
· В периоде 2 появляется значимая связь между ожиданиями IO и CPU wa (r=0.4232), хотя модель R² непригодна.
· Сильная связь переключений контекста с прерываниями (cs↔in) присутствует в обоих периодах, причём в периоде 2 модель R² становится очень высокой (0.87). Также в периоде 2 появляется высокая корреляция cs с user time (r=0.7890, R²=0.62), что может указывать на рост активности пользовательских процессов и конкуренцию за ресурсы.
1.4. ДИАГРАММЫ ПАРЕТО ПО WAIT_EVENT_TYPE И QUERYID
WAIT_EVENT (оба периода):
· IO / DataFileRead составляет 98.79% (период 1) и 99.77% (период 2) всех событий ожидания. Другие события (DataFileExtend, DataFilePrefetch, DataFileWrite) имеют незначительную долю.
QUERYID (оба периода):
· Основной потребитель ожиданий IO — запрос с идентификатором 8811732978066195686.
· Период 1:
o Количество вызовов: 2121
o Ожидания IO: 99202 (88.68% от всех IO)
o События: DataFileRead, DataFileExtend
o База данных: DB-1, роль: ROLE-1
· Период 2:
o Количество вызовов: 2241
o Ожидания IO: 125139 (89.45% от всех IO)
o События: DataFilePrefetch, DataFileRead, DataFileWrite, DataFileExtend
o База данных: DB-1, роль: ROLE-1
Итог по разделу "4. ДИАГРАММЫ ПАРЕТО ПО WAIT_EVENT_TYPE И QUERYID"
· Практически все ожидания ввода-вывода связаны с чтением файлов данных (DataFileRead).
· Запрос 8811732978066195686 генерирует около 89% всех ожиданий IO в обоих периодах. Количество вызовов запроса незначительно выросло во втором периоде (+5.7%), но количество ожиданий увеличилось на 26.1%, что может свидетельствовать об изменении плана выполнения или увеличении объёма обрабатываемых данных.
· Во втором периоде в списке событий появляются DataFilePrefetch и DataFileWrite, что указывает на возможное использование последовательного сканирования с предвыборкой и более активную запись временных файлов или модификацию данных.
Детальный анализ – граничные значения и корреляции
Ожидания СУБД
· В обоих периодах тип ожиданий IO объясняет более 99.9% всех ожиданий. Корреляция IO с общими ожиданиями равна 1.0 по определению (так как доля IO ≈ 1). Поэтому вывод о критичности IO является математическим следствием, а не дополнительным открытием. Анализ должен фокусироваться на причинах высоких ожиданий IO.
· LWLock во втором периоде демонстрирует значимую корреляцию с общими ожиданиями (r=0.7026), но ВКО = 0.0000. Это объясняется крайне малой долей LWLock в общем числе ожиданий (менее 0.1%). Согласно методике, данный тип исключается из текущего анализа. Для выяснения природы роста LWLock необходимы данные о конкретных событиях LWLock (например, WALWriteLock, BufferContent, LockManager), которые отсутствуют.
Память и буферный кэш
· shared_buffers = 16 ГБ при общем объёме RAM 62.8 ГБ и effective_cache_size = 48 ГБ. Свободная память (free) в vmstat постоянно ниже 5% (порядка 1 ГБ), что ожидаемо при агрессивном кэшировании страниц ОС (memory_cache ~55 ГБ). Свопинг отсутствует.
· В периоде 1 выявлены сильные корреляции memory_buff и memory_cache с количеством операций записи (w/s) на устройстве vdb (r=0.78 и r=0.79, R²=0.61–0.63). В периоде 2 эти корреляции становятся незначимыми. Причина изменений в буферизации ввода-вывода между периодами не ясна из имеющихся данных; требуются дополнительные срезы по типам страниц в кэше (например, через pg_buffercache).
Дисковая подсистема (I/O)
· Основное устройство данных — vdb (том /data, 2 ТБ).
· Утилизация устройства vdb (iostat %util) находится на уровне 99.9–100% в обоих периодах на протяжении 100% времени. Это указывает на то, что диск постоянно занят обработкой запросов, что является прямым подтверждением узкого места в подсистеме ввода-вывода.
· Средняя длина очереди (aqu_sz) превышает 1 в 100% времени в обоих периодах (медиана 3.72–4.03, максимум до 6.36).
· Время отклика (r_await, w_await) остаётся в пределах 1–3 мс, что для виртуализированного хранилища является приемлемым и не превышает порог 5 мс в 100% времени.
· Корреляции операционной скорости с IOPS (сумма r/s + w/s) на vdb:
o Период 1: r = -0.8625, R² = 0.7400
o Период 2: r = -0.7520, R² = 0.5700
· Корреляции с MBps (пропускной способностью) незначимы или отсутствуют.
· Вывод: Производительность ограничена количеством операций ввода-вывода в секунду (IOPS), а не пропускной способностью. Рост IOPS сопровождается снижением операционной скорости. Тип нагрузки классифицируется как «Сценарий 4» (низкая корреляция по MBps, высокая по IOPS) — узкое место в IOPS.
CPU и системные вызовы
· Загрузка CPU пользовательскими и системными процессами (us+sy) остаётся низкой (медиана us=6%, sy=6% в обоих периодах). Простой CPU (id) в среднем составляет 82–83%.
· Высокая корреляция переключений контекста (cs) с прерываниями (in) и, во втором периоде, с user time (us) может указывать на то, что процессы часто блокируются в ожидании ввода-вывода и перепланируются. Однако без данных о типе прерываний (например, сетевые, дисковые) интерпретация ограничена.
Блокировки и ожидания LWLock
· В периоде 1 LWLock практически не проявляется (все значения = 1, кроме одного пика до 2). В периоде 2 количество LWLock-ожиданий возрастает: медиана остаётся 1, но максимум достигает 2, и в конце периода фиксируется значение 2 на нескольких минутах. Рост совпадает с общим увеличением ожиданий. Природа LWLock не детализирована; требуются данные из pg_stat_activity или pg_wait_sampling по конкретным событиям LWLock.
Анализ запросов (queryid)
· Запрос 8811732978066195686 является основным генератором ожиданий IO. Отсутствует информация о тексте запроса или его плане выполнения. Без плана запроса невозможно определить, какие операции вызывают чтение (Seq Scan, Index Scan, Bitmap Heap Scan) и почему во втором периоде добавились события DataFilePrefetch и DataFileWrite. Необходимо получить:
o Текст запроса.
o План выполнения (EXPLAIN (ANALYZE, BUFFERS)).
o Статистику по таблицам, задействованным в запросе (размер, количество dead tuples, last vacuum/analyze).
2. Анализ IO
Список дисковых устройств
· vdb (данные): /data
· vdc (WAL): /wal
Граничные значения по дисковым устройствам
Устройство vdb (данные)
· r/s (чтения/с)
o Период 1: min = 3067, median = 3410, max = 3964
o Период 2: min = 3728, median = 3841, max = 5021
· rMB/s
o Период 1: min = 280, median = 290, max = 307
o Период 2: min = 285, median = 289, max = 301
· w/s (записи/с)
o Период 1: min = 29, median = 36, max = 42
o Период 2: min = 32, median = 48, max = 67
· wMB/s
o Период 1: min = 0.86, median = 0.96, max = 0.96
o Период 2: min = 0.96, median = 0.96, max = 1.22
· r_await (мс)
o Период 1: min = 0.86, median = 0.89, max = 0.93
o Период 2: min = 0.91, median = 0.98, max = 1.22
· w_await (мс)
o Период 1: min = 2.54, median = 2.60, max = 2.83
o Период 2: min = 2.54, median = 2.77, max = 3.23
· aqu_sz (глубина очереди)
o Период 1: min = 2.66, median = 3.72, max = 3.96
o Период 2: min = 3.74, median = 4.03, max = 6.36
· %util
o Период 1: min = 99.95, median = 99.96, max = 99.97
o Период 2: min = 99.91, median = 99.93, max = 99.96
Устройство vdc (WAL)
· r/s
o Период 1: min = 0, median = 0, max = 0
o Период 2: min = 0, median = 0, max = 0.02
· w/s
o Период 1: min = 13, median = 15, max = 20
o Период 2: min = 16, median = 20, max = 28
· wMB/s
o Период 1: min = 0.18, median = 0.32, max = 0.38
o Период 2: min = 0.27, median = 0.37, max = 0.56
· w_await (мс)
o Период 1: min = 0.80, median = 0.82, max = 0.83
o Период 2: min = 0.79, median = 0.80, max = 0.83
· aqu_sz
o Период 1: min = 0.02, median = 0.02, max = 0.02
o Период 2: min = 0.02, median = 0.02, max = 0.02
· %util
o Период 1: min = 3.09, median = 4.08, max = 5.16
o Период 2: min = 4.20, median = 4.87, max = 6.89
Относительные показатели iostat
· %util > 50% (% времени)
o vdb: Период 1 – 100%, Период 2 – 100%
o vdc: Период 1 – 0%, Период 2 – 0%
· r_await > 5 мс (% времени)
o vdb: Период 1 – 0%, Период 2 – 0%
o vdc: Период 1 – 0%, Период 2 – 0%
· w_await > 5 мс (% времени)
o vdb: Период 1 – 0%, Период 2 – 0%
o vdc: Период 1 – 0%, Период 2 – 0%
· aqu_sz > 1 (% времени)
o vdb: Период 1 – 100%, Период 2 – 100%
o vdc: Период 1 – 0%, Период 2 – 0%
2.1. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ "КОРРЕЛЯЦИЯ VMSTAT и IOSTAT" по дисковым устройствам
2.1.1 КОРРЕЛЯЦИЯ VMSTAT и IOSTAT
Устройство vdb:
· Корреляция wa (CPU IO wait) с %util устройства отсутствует в обоих периодах (модели непригодны). Это может быть связано с тем, что %util близок к 100% постоянно и не варьирует, а wa остаётся на уровне 5–7%.
Устройство vdc:
· В периоде 2 появляется значимая корреляция wa ↔ %util vdc (r=0.5120, R²=0.2600). Утилизация vdc остаётся низкой (медиана 4.87%), но её вариации объясняют 26% изменений wa. Это может указывать на то, что операции записи WAL, хоть и редкие, влияют на общее ожидание IO CPU.
Итог по 1.1 КОРРЕЛЯЦИЯ VMSTAT и IOSTAT
· Отсутствие корреляции wa с утилизацией основного устройства данных (vdb) объясняется постоянной высокой загрузкой диска. Утилизация vdc в периоде 2 начинает слабо коррелировать с wa, что может быть следствием увеличения интенсивности записи WAL (w/s выросло с медианы 15 до 20).
2.1.2 БУФЕРИЗАЦИЯ ВВОДА-ВЫВОДА
Устройство vdb:
· Период 1: buff ↔ wps (операций записи/с) r=0.7824, R²=0.6100 (хорошая модель).
· Период 2: корреляция buff ↔ wps становится слабой (r=0.3678) и модель непригодна.
· Корреляции buff с другими показателями (rps, rMBps, wMBps) незначимы.
Устройство vdc:
· Значимых корреляций buff с метриками vdc не выявлено.
Итог по 1.2 БУФЕРИЗАЦИЯ ВВОДА-ВЫВОДА
· В периоде 1 буферы памяти (filesystem buffer cache) активно использовались для агрегации операций записи на устройство данных. Во втором периоде эта связь ослабевает, что может быть связано с изменением характера записи (например, увеличение синхронных записей или операций fsync). Точная причина требует анализа операций записи на уровне СУБД (bgwriter, checkpoint, backend writes).
2.1.3 КЭШИРОВАНИЕ ВВОДА-ВЫВОДА
Устройство vdb:
· Период 1: cache ↔ wps r=0.7918, R²=0.6300 (хорошая модель).
· Период 2: корреляция становится незначимой.
· Аналогично буферам, связь page cache с записью ослабевает во втором периоде.
Итог по 1.3 КЭШИРОВАНИЕ ВВОДА-ВЫВОДА
· Изменение корреляционных паттернов между периодами указывает на сдвиг в профиле ввода-вывода. В периоде 2 запись на vdb становится менее предсказуемой с точки зрения кэширования ОС, что может быть следствием увеличения доли прямой записи (минуя кэш) или более частых сбросов грязных страниц.
2.1.4 КОРРЕЛЯЦИЯ ОПЕРАЦИОННОЙ СКОРОСТИ И МЕТРИК ПРОИЗВОДИТЕЛЬНОСТИ ДИСКОВОГО УСТРОЙСТВА
Устройство vdb:
· Период 1: SPEED ↔ IOPS r=-0.8625, R²=0.7400; SPEED ↔ MBps незначима.
· Период 2: SPEED ↔ IOPS r=-0.7520, R²=0.5700; SPEED ↔ MBps незначима.
Устройство vdc:
· Период 1: SPEED ↔ IOPS r=-0.7877, R²=0.6200; SPEED ↔ MBps незначима.
· Период 2: SPEED ↔ IOPS r=-0.8548, R²=0.7300; SPEED ↔ MBps незначима.
Итог по 1.4 КОРРЕЛЯЦИЯ ОПЕРАЦИОННОЙ СКОРОСТИ И МЕТРИК ПРОИЗВОДИТЕЛЬНОСТИ ДИСКОВОГО УСТРОЙСТВА
· На обоих устройствах наблюдается сильная обратная корреляция операционной скорости с IOPS (количеством операций в секунду). Модели имеют хорошее или удовлетворительное качество. Это подтверждает, что производительность лимитирована именно количеством операций ввода-вывода, а не объёмом передаваемых данных.
ИНДЕКС ПРИОРИТЕТА КОРРЕЛЯЦИИ (CPI)
Устройство vdb, Период 1:
· Ранг 1: SPEED ↔ IOPS, CPI = 0.8610
· Ранг 2: cache ↔ wps, CPI = 0.3927
· Ранг 3: buff ↔ wps, CPI = 0.0000
Устройство vdb, Период 2:
· Ранг 1: SPEED ↔ IOPS, CPI = 0.0000
Устройство vdc, Период 1:
· Ранг 1: SPEED ↔ IOPS, CPI = 0.0000
Устройство vdc, Период 2:
· Ранг 1: SPEED ↔ IOPS, CPI = 0.8545
· Ранг 2: wa ↔ %util, CPI = 0.0000
Примечание: Нулевые значения CPI в отчётах _3.1.test.vmstat_iostat.txt и _3.vmstat_iostat.txt могут быть следствием округления или особенностей расчёта. В периоде 2 для vdc корреляция SPEED ↔ IOPS получила CPI=0.8545.
Итог по разделу "СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ "КОРРЕЛЯЦИЯ VMSTAT и IOSTAT" по дисковым устройствам"
· Основной вывод подтверждается для обоих устройств: операционная скорость СУБД обратно коррелирует с IOPS. Устройство vdb работает на пределе своих возможностей по IOPS (утилизация 100%). Устройство vdc демонстрирует низкую утилизацию, но его IOPS также коррелирует со скоростью, что может быть связано с синхронными операциями записи WAL, влияющими на время отклика транзакций.
Проблемы инфраструктуры по итогам сравнительного анализа
· Устройство vdb (данные) постоянно перегружено операциями ввода-вывода (утилизация ≈100%, очередь >1). Это является прямым ограничением производительности.
· Рост максимальных значений w/s и wMB/s на vdb во втором периоде указывает на увеличение нагрузки на запись.
· Появление событий DataFileWrite и DataFilePrefetch для основного запроса во втором периоде может быть связано с возросшей записью временных файлов или изменением стратегии доступа к данным.
3. Итог
3.1 Ключевые проблемы
1. Высокие ожидания ввода-вывода (IO), составляющие >99% всех ожиданий СУБД. Основное событие — DataFileRead.
2. Насыщение дискового устройства данных (vdb) по IOPS — утилизация 100% на протяжении всего времени наблюдения, очередь запросов постоянно >1.
3. Основной генератор нагрузки — запрос 8811732978066195686, ответственный за ~89% ожиданий IO.
4. Снижение операционной скорости во втором периоде (отрицательный тренд) при одновременном росте ожиданий и усилении влияния записи.
5. Появление признаков роста нагрузки на WAL и записи данных во втором периоде: увеличение w/s на vdb и vdc, появление событий DataFileWrite, усиление корреляции SPEED ↔ IOPS на vdc.
3.2 Проблемы СУБД
· Доминирование ожиданий IO/DataFileRead указывает на интенсивное чтение страниц с диска, которые отсутствуют в буферном кэше PostgreSQL или в page cache ОС. Несмотря на значительный shared_buffers (16 ГБ) и effective_cache_size (48 ГБ), объём данных, к которым обращается запрос, вероятно, превышает доступную память, либо запрос выполняет последовательное сканирование больших таблиц, вытесняя кэш.
· Отсутствие детализации по LWLock не позволяет оценить, связан ли рост этого типа ожиданий с конфликтами доступа к буферам или WAL.
· Параметры autovacuum настроены агрессивно (naptime=1s, scale factor=0.01), но данных о работе autovacuum (количество dead tuples, время последнего vacuum) нет. Невозможно определить, способствует ли bloat таблиц увеличению объёма читаемых данных.
3.3 Проблемы инфраструктуры
· Дисковое устройство vdb (LVM на одном виртуальном диске) не справляется с пиковой нагрузкой по IOPS. В периоде 2 максимальное количество операций чтения достигает 5021 в секунду, записи — 67 в секунду при глубине очереди до 6.36.
· Время отклика остаётся приемлемым (до 3.2 мс), но постоянная очередь говорит о перегрузке. Увеличение IOPS со стороны СУБД напрямую приводит к падению производительности.
· Устройство WAL (vdc) имеет низкую утилизацию, но его влияние на общую производительность через синхронные записи (например, при commit) во втором периоде усиливается.
4. Заключение
На основе предоставленных данных за два последовательных часа установлено, что производительность СУБД PostgreSQL лимитирована возможностями дисковой подсистемы по количеству операций ввода-вывода в секунду (IOPS). Основной вклад в нагрузку вносит один запрос, выполняющий интенсивное чтение данных (событие DataFileRead). Во втором периоде наблюдается ухудшение тренда операционной скорости, рост доли записи и увеличение корреляции скорости с IOPS на устройстве WAL.
Ограничения анализа:
· Отсутствует информация о тексте и плане выполнения запроса 8811732978066195686. Без неё невозможно определить, можно ли оптимизировать запрос (например, добавить индексы, изменить структуру запроса).
· Нет данных о размере таблиц, индексов, статистике обращений к блокам (pg_statio_user_tables, pg_stat_user_indexes). Неизвестен hit ratio буферного кэша PostgreSQL.
· Нет детализации по событиям LWLock, что не позволяет исключить блокировки как вторичную причину деградации.
· Не предоставлены сведения о конфигурации хранилища (тип дисков, политики кэширования гипервизора), что ограничивает интерпретацию высоких значений утилизации при низком времени отклика.
Для углублённого анализа и выработки конкретных действий необходимо собрать:
· План выполнения проблемного запроса с BUFFERS.
· Статистику по таблицам, участвующим в запросе (pg_stat_user_tables, pg_class).
· Данные о работе контрольных точек и bgwriter (pg_stat_bgwriter).
· Профиль ожиданий LWLock (pg_wait_sampling, pgpro_stats).
· Информацию о типе и параметрах дискового хранилища.