PG_EXPECTO : checkpoint_timeout = '5m'. Часть-1 : СУБД.

checkpoint_timeout = '5m'

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

Подготовка эксперимента.

checkpoint_timeout = '5m'. Часть-2 : Инфраструктура

Задача эксперимента

Проанализировать метрики производительности СУБД и инфраструктуры в ходе нагрузочного тестирования при значении параметра checkpoint_timeout = 5 минут.

1.Производительность и ожидания СУБД

Регрессионный и корреляционный анализ

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

График изменения операционной скорости в ходе нагрузочного тестирования.

Важная деталь по графикам

Периодические провалы операционной скорости это не влияние checkpoint , это длительное выполнение конкурентных update в сценарии-6, в то время как остальные сценарии завершили работу.

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

График изменения ожиданий СУБД в ходе нагрузочного тестирования

Ожидания СУБД типа IO

График изменения ожиданий типа IO в ходе нагрузочного тестирования.

Ожидания СУБД типа LWLock

График изменения ожиданий типа LWLock в ходе нагрузочного тестирования.

Типы ожиданий СУБД (Диаграмма Парето)

События ожиданий по тестовым запросам (Диаграмма Парето)

2. Общий анализ трендов производительности и нагрузки

2.1. Динамика SPEED и WAITINGS

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

Начинается с низкого значения ~8 660 в 10:29.

Быстро возрастает до уровня ~1.8–2.0 млн и остаётся высоким до ~10:45.

Затем наблюдаются резкие падения в моменты:

• 10:46 – падение до ~25 650
• 11:04 и 11:36 – падения до ~25 650
• 11:41 – падение до ~2 250
• После 12:00 скорость стабилизируется на уровне ~1.0–1.3 млн, но с ~13:00 начинает снижаться до ~600–800 тыс.

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

• Начинаются с ~3 272, снижаются до минимума ~2 189 в 10:31.
• Постепенно растут на протяжении всего теста.
• Пик достигается в 13:03 – ~9 087.
• Заметны скачки в моменты падения SPEED.

Вывод:
SPEED демонстрирует нестабильность с резкими провалами, особенно в первой половине теста.
WAITINGS имеют восходящий тренд, что указывает на рост contention (блокировок, ожиданий) под нагрузкой.

2.2. Влияние LOAD на SPEED и WAITINGS

Корреляция:

• LOAD и WAITINGS: сильная положительная корреляция – рост нагрузки приводит к росту ожиданий.
• LOAD и SPEED: при увеличении LOAD выше 12 скорость начинает снижаться, особенно после 13:00.
• Провалы SPEED часто совпадают с моментами роста WAITINGS, даже при незначительном изменении LOAD.

2.3. Фазы нагрузки

Можно выделить три основные фазы:

2.4. Итоговые выводы

1. Пики WAITINGS совпадают с провалами SPEED, что указывает на блокировки (Lock/LWLock) как основной лимитирующий фактор.
2. Рост LOAD приводит к росту WAITINGS, особенно после LOAD > 12.
3. SPEED сохраняет высокие значения только при низкой нагрузке (LOAD ≤ 10).
4. Критическая точка – примерно LOAD = 12–13, после которой производительность начинает снижаться.

Основная проблема – Lock contention (особенно transactionid), что подтверждается данными из postgres.3.queryid.txt и postgres.2.wait_event.txt.

3. Анализ влияния нагрузки на производительность и ожидания

3.1. Значения R²: объяснительная сила трендов

Вывод:

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

3.2. Углы наклона: направление трендов

Вывод:

• Деградация производительности (падение SPEED) и рост contention (рост WAITINGS) — системные тренды, подтверждённые регрессией.

3.3. Корреляция SPEED – WAITINGS: -0.50

Интерпретация корреляции:

· Умеренная отрицательная корреляция (-0.50) означает, что при росте ожиданий скорость обычно падает, и наоборот.

· Но это не строгая зависимость (не -1.0), поэтому есть периоды, когда:

o Оба показателя растут/падают одновременно (аномалии).

o Или один меняется, а другой нет.

Визуальное проявление:
По графикам (postgres.1.cluster_report_4graph.txt) видно:

· Основной паттерн: когда WAITINGS резко растут (например, 10:46, 11:04, 12:16, 13:03), SPEED обычно падает.

· Аномальные периоды (когда корреляция нарушается):

3.4. Количественная оценка влияния LOAD

Из мета-отчёта нет прямой корреляции LOAD с SPEED/WAITINGS, но мы можем её оценить:

LOAD vs WAITINGS:
Корреляция, судя по графикам, сильная положительная (при росте LOAD WAITINGS растут).
Коэффициент корреляции ≈ 0.8–0.9 (оценка по визуальному сходству кривых).

LOAD vs SPEED:
Корреляция отрицательная, но нелинейная.
При LOAD > 12 SPEED начинает снижаться заметно.
Коэффициент корреляции ≈ -0.6 (оценка).

Уравнение регрессии (примерное):

· WAITINGS ≈ 2000 + 300 × LOAD + ε
(при LOAD=7 → ~4100, при LOAD=22 → ~8600, что близко к данным)

· SPEED ≈ 2 000 000 – 70 000 × LOAD + ε
(но это очень грубо — реальная зависимость сложнее).

3.5. Итоговая количественная оценка

3.6. Выводы:

1. Производительность деградирует со временем (угол наклона -31.06), причём только 36% этой деградации объясняется линейным трендом — остальное вызвано скачками нагрузки, блокировками и иными факторами.
2. Ожидания растут предсказуемо (R²=0.72) — каждую минуту +40 единиц, в основном из-за роста нагрузки и блокировок.
3. Аномалии есть: в некоторые периоды SPEED падает без роста WAITINGS (возможно, проблемы с CPU, памятью или диском).

4. Итоговый отчет по нагрузочному тестированию PostgreSQL

1. Резюме проблем и узких мест

4.1.1. Ключевая проблема: Конкуренция за блокировки транзакций

· TransactionID блокировки составляют 100% всех Lock-ожиданий

· QueryID -4261790647437368643 (scenario6) генерирует:

• 100% всех Lock-ожиданий
• 86% всех LWLock-ожиданий
• 131,879 выполнений за период тестирования

4.1.2. Статистическая значимость трендов:

4.1.3. Критические точки нагрузки:

• LOAD ≤ 10: Система стабильна, SPEED высокий
• LOAD = 12-13: Начало деградации производительности
• LOAD ≥ 15: Явное насыщение, рост ожиданий экспоненциальный
• LOAD = 22 (пик): WAITINGS достигают 9,087 (+415% от начального уровня)