Найти в Дзене
Postgres DBA

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

GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL Проанализировать метрики производительности СУБД и инфраструктуры в ходе нагрузочного тестирования при значении параметра checkpoint_timeout = 15 минут. Периодические провалы операционной скорости это не влияние checkpoint , это длительное выполнение конкурентных update в сценарии-6, в то время как остальные сценарии завершили работу. Операционная скорость и ожидания СУБД демонстрируют обратную зависимость (коэффициент корреляции −0.63). При росте ожиданий производительность падает. Рост нагрузки приводит к росту ожиданий и снижению производительности. 1. Фаза стабильной низкой нагрузки: 2. Фаза роста нагрузки: 3. Фаза высокой нагрузки: 4. Фаза стабильной высокой нагрузки: Доминирующие категории ожиданий: Ключевой вывод: 96% вариаций общих ожиданий (ОЖИДАНИЯ) объясняются изменениями в ожиданиях блокировок (LOCK). Абсолютные значения (MIN → MAX): Изменение долей в те
Оглавление
checkpoint_timeout = '15m'
checkpoint_timeout = '15m'

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

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

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

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

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

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

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

-2

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

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

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

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

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

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

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

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

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

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

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

-7

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

-8

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

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

Операционная скорость и ожидания СУБД демонстрируют обратную зависимость (коэффициент корреляции −0.63). При росте ожиданий производительность падает.

2.2. Влияние нагрузки на операционной скорости и ожидания СУБД:

Рост нагрузки приводит к росту ожиданий и снижению производительности.

2.3. Основные фазы нагрузки:

1. Фаза стабильной низкой нагрузки:

  • НАГРУЗКА = 7–8
  • ОПЕРАЦИОННАЯ СКОРОСТЬ высокая, ОЖИДАНИЯ умеренные (3,6–5,5 тыс.)
  • Система работает эффективно.

2. Фаза роста нагрузки:

  • НАГРУЗКА увеличивается с 8 до 13
  • ОПЕРАЦИОННАЯ СКОРОСТЬ начинает колебаться, ОЖИДАНИЯ растут (4.1–6.6 тыс.)
  • Появляются признаки деградации производительности.

3. Фаза высокой нагрузки:

  • НАГРУЗКА растет с 13 до 22
  • ОПЕРАЦИОННАЯ СКОРОСТЬ падает до минимальных значений, ОЖИДАНИЯ достигают 8–10 тыс.
  • Система сильно нагружена, производительность низкая.

4. Фаза стабильной высокой нагрузки:

  • НАГРУЗКА = 22
  • ОПЕРАЦИОННАЯ СКОРОСТЬ стабильно низкая, ОЖИДАНИЯ стабильно высокие (≈ 10 тыс.)
  • Система работает на пределе.

2.4. Ключевые выводы:

  • Основная проблема — рост ожиданий типа Lock и LWLock, что указывает на конкуренцию за ресурсы (транзакции, буферы).
  • Критический порог нагрузки — около 12–13 активных сессий, после которого производительность резко падает.

2.5. Основные категории ожиданий и их вклад

Доминирующие категории ожиданий:

  • LOCK (блокировки) - наибольший вклад (корреляция : 0.96)
  • LWLOCK (легковесные блокировки) - второй по значимости (корреляция: 0.86)
  • TIMEOUT (таймауты) - умеренный вклад (корреляция: -0.41)
  • IO (ввод/вывод) - наименьший вклад (корреляция: -0.56)

Ключевой вывод: 96% вариаций общих ожиданий (ОЖИДАНИЯ) объясняются изменениями в ожиданиях блокировок (LOCK).

2.6. Динамика абсолютных значений и долей

Абсолютные значения (MIN → MAX):

  • LOCK: 1,308 → 8,390 (рост в 6.4 раза)
  • LWLOCK: 54 → 338 (рост в 6.3 раза)
  • TIMEOUT: 654 → 3,440 (рост в 5.3 раза)
  • IO: 58 → 126 (рост в 2.2 раза)
  • ОЖИДАНИЯ: 3,654 → 10,128 (рост в 2.8 раза)

Изменение долей в течение теста:

  • Доля LOCK в ОЖИДАНИЯ: увеличивается с ≈30% (в начале) до ≈83% (в конце теста)
  • Доля LWLOCK: относительно стабильна (1-3%)
  • Доля TIMEOUT: снижается с ≈67% до ≈13%
  • Доля IO: минимальна (1-2%)

2.7. Основные причины задержек (по Парето)

Ведущие события ожиданий:

1. Lock/transactionid - 89.77% от всех событий Lock

2. LWLock/LockManager - 63.72% от LWLock

3. LWLock/BufferMapping - 22.48% от LWLock

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

3.1. Анализ значений R² и наклонов регрессии

Коэффициенты детерминации R²:

  • ОЖИДАНИЯ: R² = 0.84 - высокое значение показывает, что 84% изменчивости ожиданий объясняется линейной зависимостью от времени/нагрузки. Это указывает на сильную систематическую зависимость роста ожиданий от увеличения нагрузки.
  • ОПЕРАЦИОННАЯ СКОРОСТЬ: R² = 0.47 - относительно низкое значение означает, что только 47% изменчивости производительности объясняется линейной моделью. Это говорит о том, что на производительность влияют другие факторы помимо нагрузки (например, блокировки, состояние кэша, конкретные запросы).

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

  • ОПЕРАЦИОННАЯ СКОРОСТЬ: наклон -34.51 - отрицательный наклон показывает тенденцию к снижению производительности со временем/при увеличении нагрузки. На каждую единицу времени производительность в среднем уменьшается на ~34.5 единицы.
  • ОЖИДАНИЯ: наклон +42.43 - положительный наклон показывает тенденцию к росту ожиданий со временем/при увеличении нагрузки. На каждую единицу времени ожидания в среднем увеличиваются на ~42.4 единицы.

3.2. Анализ корреляции SPEED-WAITINGS (-0.63)

Статистическая интерпретация:

Отрицательная корреляция -0.63 указывает на умеренную обратную связь: когда ожидания растут, производительность имеет тенденцию снижаться.

3.3. Количественная оценка влияния нагрузки

Связь нагрузки и производительности:

1. Начальная фаза (НАГРУЗКА=7-8): производительность достигает пика (до 2.38M)

2. Средняя фаза (НАГРУЗКА=9-15): производительность колеблется в диапазоне 1-2M

3. Высокая нагрузка (НАГРУЗКА=18-22): производительность падает до 0.5-1.4M

Основные выводы:

1. Деградация производительности: при увеличении нагрузки с 7 до 22 (в 3.1 раза) производительность снижается с ~2.38M до ~1.34K (в 1776 раз). Это указывает на нелинейную деградацию.

2. Рост ожиданий: общие ожидания увеличиваются с 4,400 до 10,128 (в 2.3 раза), при этом:

  • LOCK ожидания растут с 1,308 до 8,390 (в 6.4 раза)
  • LWLock ожидания растут с 54 до 338 (в 6.3 раза)

3. Критические точки:

o Переломный момент при НАГРУЗКА=15 - резкое ускорение деградации

o Дополнительное ухудшение при НАГРУЗКА=22

4. Сводный анализ

4.1. Доминирование блокировок как главная проблема

  • Ожидания типа Lock (в основном transactionid) составляют ~90% от всех событий ожидания.
  • Корреляция между общим числом ожиданий (WAITINGS) и блокировками (LOCK) составляет 0,96, что указывает на прямую зависимость производительности от конкуренции за транзакционные блокировки.
  • Легковесные блокировки (LWLock) также значимы (корреляция 0,86), особенно LockManager и BufferMapping.

4.2. scenario6() – основной источник проблем

Запрос scenario6() (QUERYID: -4261790647437368643) является причиной:

  • 100% ожиданий типа Lock;
  • 79% ожиданий типа LWLock.

Выполнен 128 816 раз за период теста, что указывает на его высокую активность и влияние на общую производительность.

4.3. Зависимость от нагрузки

С увеличением нагрузки (LOAD с 7 до 22) наблюдаются:

  • Рост общего числа ожиданий (WAITINGS с ~4 400 до ~10 128);
  • Увеличение количества блокировок (LOCK с ~1 308 до ~8 390);
  • Нестабильность производительности (SPEED), особенно при переходе нагрузки через порог ~8–10.

Отрицательная корреляция (-0,63) между SPEED и WAITINGS подтверждает, что рост ожиданий снижает скорость работы СУБД.