Сравнительный анализ результатов нагрузочного тестирования "Тантор Лабс", после применения рекомендаций PG_EXPECTO + DeepSeek.

Сравнительный анализ результатов нагрузочного тестирования

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

Эксперимент‑1 (базовый) – настройки, сгенерированные «Тантор Лабс» (pgconfigurator).

Период наблюдения: 2026‑03‑05 18:09 – 20:31 (2 ч 22 мин, 143 точки).

Эксперимент‑2 (оптимизированный) – настройки, рекомендованные PG_EXPECTO + DeepSeek.

Период наблюдения: 2026‑03‑06 10:48 – 13:10 (2 ч 22 мин, 143 точки).

Аппаратная платформа (одинакова для обоих экспериментов):

• CPU: 8 ядер (Intel Xeon Skylake, виртуализация KVM)
• RAM: 7,5 GB
• Диски: LVM, отдельные тома для /data (pg_data), /wal, /log

Сравнение конфигурации СУБД и операционной системы

Изменённые параметры PostgreSQL

shared_buffers

• Эксперимент‑1: 1779 MB
• Эксперимент‑2: 3 GB

max_wal_size

• Эксперимент‑1: 2021 MB
• Эксперимент‑2: 5 GB

checkpoint_timeout

• Эксперимент‑1: 15 min
• Эксперимент‑2: 30 min

bgwriter_delay

• Эксперимент‑1: 54 ms
• Эксперимент‑2: 100 ms

bgwriter_lru_maxpages

• Эксперимент‑1: 515
• Эксперимент‑2: 1000

bgwriter_lru_multiplier

• Эксперимент‑1: 7,0
• Эксперимент‑2: 4,0

Изменённые параметры ядра (vm)

vm.dirty_background_ratio

• Эксперимент‑1: 10 %
• Эксперимент‑2: 2 %

vm.dirty_ratio

• Эксперимент‑1: 30 %
• Эксперимент‑2: 10 %

vm.dirty_writeback_centisecs

• Эксперимент‑1: 500
• Эксперимент‑2: 200

Остальные настройки (work_mem, maintenance_work_mem, wal‑уровни, автовакуум, etc.) остались без изменений.

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

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

SPEED :

• Эксперимент‑1: минимум 375 955, медиана 383 994, максимум 683 866.
• Эксперимент‑2: минимум 472 713, медиана 539 761, максимум 749 919.

Медианная скорость выросла на 40,6 %.

WAITINGS :

• Эксперимент‑1: минимум 48 536, медиана 78 011, максимум 226 349.
• Эксперимент‑2: минимум 47 168, медиана 76 311, максимум 254 309.

Медианные ожидания снизились на 2,2 %, хотя максимальные выросли – возможно, из‑за более интенсивной нагрузки.

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

Тренд SPEED

• Эксперимент‑1: R² = 0,77 (хорошая модель), угол наклона +41,33
• Эксперимент‑2: R² = 0,89 (очень высокая), угол наклона +43,29
• В обоих случаях скорость растёт, во втором эксперименте тренд чуть круче.

Тренд WAITINGS

• Эксперимент‑1: R² = 0,87 (очень высокая), угол +43,01
• Эксперимент‑2: R² = 0,86 (очень высокая), угол +42,90
• Ожидания также растут синхронно со скоростью.

Регрессия SPEED по WAITINGS

• Эксперимент‑1: R² = 0,97, угол +44,56
• Эксперимент‑2: R² = 0,99, угол +44,84
• Связь исключительно сильная, почти линейная.

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

В обоих экспериментах доминирующий тип ожиданий – IO:

• Интегральный приоритет IO = 0,6271.
• Взвешенная корреляция ожиданий (ВКО) для IO = 1,0 (критическое значение).

Остальные типы (IPC, Lock, LWLock, Timeout) имеют статистически значимые корреляции, но ВКО < 0,01 – игнорируются.

Итог по разделу

Основной источник задержек – операции ввода‑вывода. Прочие типы ожиданий не оказывают заметного влияния на общую нагрузку.

2. Сравнительный трендовый анализ производительности vmstat

Ключевые метрики (медианы за период)

procs → r (процессы в очереди на выполнение)

• Эксперимент‑1: 3 (диапазон 2–4)
• Эксперимент‑2: 3 (диапазон 2–5)
• Характер тренда: негативный, R² ~0,75 (высокая скорость ухудшения)

procs → b (процессы в uninterruptible sleep)

• Эксперимент‑1: 14 (9–40)
• Эксперимент‑2: 14 (9–40)
• Характер тренда: негативный, R² ~0,86 (очень высокая скорость)

cpu → wa (процент простоя CPU в ожидании IO)

• Эксперимент‑1: 62 % (58–67)
• Эксперимент‑2: 61 % (54–63)
• Характер тренда: статистически незначим

cpu → id (процент полного простоя CPU)

• Эксперимент‑1: 14 % (2–19)
• Эксперимент‑2: 12 % (1–18)
• Характер тренда: негативный, R² ~0,93 (резкое падение idle)

Негативные тренды по очередям выполнения (r) и блокированным процессам (b) сохраняются, процессорное время простоя (id) быстро сокращается.

Итог по разделу

Система испытывает хроническую перегрузку по вводу‑выводу: более 50 % времени wa > 10 %, очередь процессов в состоянии b постоянно превышает количество ядер CPU.

3. Сравнительный статистический анализ ожиданий СУБД и метрик vmstat

Связь IO с чтением (bi) и записью (bo)

IO ↔ bi

• Эксперимент‑1: корреляция 0,55, R² = 0,31 (слабая модель)
• Эксперимент‑2: корреляция 0,82, R² = 0,67 (хорошая модель)
• После оптимизации - чтение с диска стало гораздо сильнее влиять на IO‑ожидания.

IO ↔ bo

• Эксперимент‑1: корреляция 0,85, R² = 0,72 (хорошая)
• Эксперимент‑2: корреляция 0,75, R² = 0,56 (удовлетворительная)
• Влияние записи немного ослабло – возможно, благодаря увеличению max_wal_size и checkpoint_timeout.

Анализ переключений контекста (cs)

• cs ↔ in (прерывания): корреляция ~0,996, R² = 0,99
• cs ↔ us (user time): корреляция ~0,99, R² = 0,99
• cs ↔ sy (system time): корреляция ~0,97, R² ~0,95
• Во всех случаях связь исключительно сильная. Высокая интенсивность переключений контекста и прерываний сохраняется.

Влияние на буферный кэш

Shared buffers hit ratio

• Эксперимент‑1: медиана 96,64 % (min 96,09, max 98,36)
• Эксперимент‑2: медиана 96,95 % (min 96,48, max 98,47)
• Небольшое улучшение попаданий в кэш.

Скорость ↔ прочитанные блоки

• Эксперимент‑1: корреляция 0,58, R² = 0,34 (слабая)
• Эксперимент‑2: корреляция несущественна
• После увеличения shared_buffers скорость перестала зависеть от объёма чтения с диска.

Грязные страницы (dirty pages)

• Размер dirty pages (KB): медиана снизилась с 7126 до 6972, максимум с 18146 до 15672.
• dirty pages ↔ b (процессы в uninterruptible sleep): корреляция ~0,992, R² = 0,98 (чрезвычайно сильная) – проблема сохраняется.
• dirty pages ↔ bo: корреляция снизилась с 0,86 до 0,79, R² с 0,74 до 0,62 – механизм обратной записи стал немного эффективнее.
• dirty pages ↔ sy: корреляция ~0,975, R² = 0,95 – высокие накладные расходы ядра на управление памятью.

Доступная память

• available_mem_mb: медиана упала с 4883 MB до 3528 MB (из‑за увеличения shared_buffers). Доля времени со свободной RAM <5 % по‑прежнему 100 %.

Итог по разделу

Увеличение shared_buffers и настройка контрольных точек позволили улучшить попадания в кэш и немного сгладить пики записи, однако фундаментальные проблемы с памятью (дефицит свободной RAM) и перегрузкой ввода‑вывода (процессы в состоянии b, высокий wa) остаются.

4. Сравнение диаграмм Парето по wait_event_type и queryid

Типы ожиданий (wait_event_type)

• Эксперимент‑1: IO (DataFileRead) – 14 159 430 событий, 99,84 %
• Эксперимент‑2: IO (DataFileRead) – 13 790 683 события, 99,94 %
• Абсолютное число событий IO немного снизилось, их доля осталась подавляющей.

Запросы (queryid)

• Эксперимент‑1: запрос select scenario1() (ID 8275902800498673318) – 85,04 % всех ожиданий.
• Эксперимент‑2: запрос select scenario1() (ID 6751319641472471819) – 85,03 % всех ожиданий.
• Основным потребителем ресурсов остаётся один и тот же сценарий (scenario1).

Итог по разделу

Узкое место не изменилось – это по‑прежнему чтение данных с диска (DataFileRead), генерируемое запросом scenario1. Оптимизация не затронула логику самого запроса.

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

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

• IO – единственный значимый тип (ВКО = 1,0).
• IPC, Lock, LWLock, Timeout – корреляции есть, но вклад в общую нагрузку ничтожен (ВКО < 0,01).

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

• shared_buffers увеличены с 1,8 GB до 3 GB.
• hit ratio вырос на 0,3 п.п. (медиана 96,95 %).
• Доступная память снизилась на ~1,4 GB, дефицит свободной RAM сохраняется (100 % времени <5 %).
• Грязные страницы: объём немного уменьшился, но их влияние на блокировку процессов (b) осталось критическим.

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

• Чтение (bi) стало значительно сильнее коррелировать с ожиданиями IO (R² вырос с 0,31 до 0,67).
• Запись (bo) коррелирует чуть слабее, чем раньше, что может указывать на более плавную запись благодаря увеличенному max_wal_size.
• Процессы в состоянии b по‑прежнему сильно зависят от объёма грязных страниц (r² = 0,98).
• Процент времени с wa >10 % – 100 % в обоих экспериментах.

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

• Переключения контекста (cs) тесно связаны с прерываниями (in) и user/system time – все корреляции >0,97.
• System time (sy) сильно коррелирует с размером грязных страниц (r² = 0,95) – ядро тратит много ресурсов на управление памятью.
• Процессорное время простоя (id) продолжает падать (негативный тренд, R² >0,9).

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

• Корреляции для Locks и LWLocks статистически значимы, но их вес в общей структуре ожиданий ничтожен (ВКО < 0,01).
• Основная блокировка – ожидание IO, а не внутренние блокировки PostgreSQL.

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

• Запрос scenario1 генерирует 85 % всех ожиданий (DataFileRead).
• Остальные запросы (scenario2, scenario3) вносят пренебрежимо малый вклад.

Ключевые проблемы для экспериментов

Эксперимент‑1 («Тантор Лабс»)

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

• Недостаточный размер shared_buffers (1,8 GB) – низкая эффективность кэширования.
• Слишком частые контрольные точки (checkpoint_timeout = 15 мин, max_wal_size = 2 GB) – пиковые нагрузки на запись.
• Агрессивная работа bgwriter (bgwriter_lru_multiplier = 7) могла вызывать лишние сбросы.

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

• Свободной памяти <5 % в течение всего теста – риск вытеснения страниц.
• Высокий процент IO‑wait (wa >10 % всегда) и очередь процессов в состоянии b (превышение ядер CPU 100 % времени).
• Грязные страницы накапливаются до 18 MB, вызывая блокировки процессов.
• Высокие накладные расходы ядра (sy) из‑за управления памятью.

Эксперимент‑2 (PG_EXPECTO + DeepSeek)

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

• Основной запрос scenario1 не оптимизирован – по‑прежнему 85 % ожиданий приходится на чтение с диска.
• Несмотря на увеличение shared_buffers, hit ratio остаётся на уровне 97 %, что недостаточно для полного устранения дисковых чтений.

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

• Дефицит свободной памяти усугубился (доступно ~3,5 GB вместо ~4,9 GB) – плата за увеличение shared_buffers.
• IO‑wait и блокировки процессов (b) остались на прежнем критическом уровне.
• Системные вызовы и переключения контекста по‑прежнему крайне высоки.

Итоговый анализ влияния мероприятий

1. Производительность (скорость) выросла на 40 % – это главный положительный эффект.💥

Увеличение shared_buffers, размера WAL и интервала контрольных точек позволило эффективнее использовать кэш и сгладить пики записи.

2. Нагрузка на ввод‑вывод частично перераспределилась

• Корреляция IO с чтением (bi) стала сильнее – теперь чтения из файлов данных лучше отражаются в ожиданиях.
• Корреляция с записью (bo) немного ослабла – запись стала более равномерной.

3. Проблемы операционной системы не устранены

• Свободная память уменьшилась, и её дефицит сохраняется.
• Процессы в состоянии b и высокий IO‑wait остались на прежнем уровне.
• Переключения контекста и нагрузка на ядро не снизились.

4. Запрос‑виновник не оптимизирован

Более 85 % ожиданий по‑прежнему приходятся на select scenario1(). Без изменений в логике запроса или добавления индексов дальнейший рост скорости ограничен.

Общий вывод:

1. Проведённая оптимизация дала значительный прирост производительности (медианная скорость +40,6 %) за счёт более эффективного использования памяти и сглаживания записи.
2. Однако инфраструктурные ограничения (нехватка RAM, медленная дисковая подсистема) и неоптимизированный запрос остаются «узкими горлами».
3. Для дальнейшего улучшения необходимы либо аппаратный апгрейд (больше памяти, более быстрые диски), либо глубокая оптимизация запроса scenario1 (индексы, рефакторинг).