PG_EXPECTO v.7+DeepSeek: Статистическая обработка данных и формирование сравнительных отчетов OLTP vs OLAP.

OLTP vs OLAP: Один сервер, два характера. Статистический анализ pg_expecto и выводы DeepSeek

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

Глоссарий терминов | Postgres DBA | Дзен

Сравнение OLTP и OLAP нагрузок на PostgreSQL — задача, требующая глубокого погружения в метрики. Чтобы исключить субъективные оценки и автоматизировать формирование выводов, используется связка инструментов: сбор и статистическая обработка данных выполнялись утилитой pg_expecto, а подготовка итоговых аналитических отчетов — языковой моделью DeepSeek на основе заранее подготовленных промптов.

Предыдущие работы по теме имитации нагрузки OLAP/OLTP в ходе нагрузочного тестирования

Версия 6.

Версия 5.

Особенности версии 7.

Имитация и анализ паттернов нагрузки OLAP/OLTP с использованием версии 7.

Нагрузка на СУБД

Имитация OLTP нагрузки

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

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

Имитация OLAP нагрузки

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

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

Краткий сравнительный анализ статистических данных СУБД и инфраструктуры

Сформируй краткий сравнительный отчет по производительности СУБД и инфраструктуры:

Эксперимент-1(нагрузка имитирующая OLTP)

Эксперимент-2(нагрузка имитирующая OLAP)

Для формирования отчета используй списки, вместо таблиц.

Состав отчета:

# Существенные различия метрик производительностим СУБД и инфраструктуры

# Главный итог влияния типа нагрузки на производительность СУБД и инфраструктуры

Сравнительный отчет: OLTP vs OLAP

Существенные различия метрик производительности СУБД и инфраструктуры

Операционная скорость (TPS/Speed)

• OLTP: Медианная скорость в 4,3 раза выше, чем при OLAP. Скорость стабильно высокая (медиана ~541k против ~125k в OLAP).
• OLAP: Скорость существенно ниже и имеет негативный тренд роста ожиданий, что говорит о насыщении системы.

Основной тип ожидания (Wait Event)

• OLTP: Доминирует IO (Интегральный приоритет ~0.63). 84% всех ожиданий приходятся на один запрос (события DataFileRead/Write). Система упирается в диск.
• OLAP: Доминирует IPC (Интегральный приоритет ~0.85), за ним следует Timeout и LWLock. Ожидания IO лишь на 4-м месте. Проблема в межпроцессном взаимодействии и синхронизации, а не в чистом IO.

Состояние процессов и CPU (vmstat)

• OLTP: Наблюдается критический рост процессов в состоянии непрерываемого сна (procs b) и процента ожидания IO (cpu wa). Тренд резко ухудшающийся (коэф. тренда ~40). Система массовно блокируется в ожидании диска.
• OLAP: Очередь на выполнение (procs r) растет, что указывает на конкуренцию за CPU. При этом процент простоя CPU (cpu id) снижается, но полезной работы не прибавляется — CPU тратит время на переключение контекста и системные вызовы (IPC, LWLocks).

Эффективность кэширования (Shared Buffers Hit Ratio)

• OLTP: Высокий Hit Ratio (медиана ~97%). Данные хорошо помещаются в кэше, но даже небольшое количество чтений с диска создает критическую нагрузку.
• OLAP: Низкий Hit Ratio (медиана ~59%). Это характерно для аналитических запросов, которые сканируют большие объемы данных, не помещающиеся в shared_buffers.

Статистика "грязных" страниц (Dirty Pages)

• OLTP: Размер "грязных" страниц большой (медиана ~10 MB). Наблюдается сильная корреляция между размером dirty pages и процессами в ожидании IO (b, wa). Фоновая запись не успевает, процессы блокируются.
• OLAP: Размер "грязных" страниц значительно ниже (медиана ~3 MB). Это указывает на то, что нагрузка больше читающая, чем пишущая.

Ключевые корреляции

• OLTP: Основные проблемы завязаны на диск и память ОС: cs(переключения контекста) коррелирует с us(user time), а dirty pages — с b/wa. Система тормозит из-за сброса данных на диск.
• OLAP: Основные проблемы завязаны на CPU и ядро СУБД: IPC/Timeout сильно коррелируют с sy(system time) и in(прерываниями). CPU тратит время на обработку сигналов, таймеров и переключение контекста, а не на полезную работу.

Главный итог влияния типа нагрузки на производительность СУБД и инфраструктуры

Главный итог для OLTP: Нагрузка упирается в производительность дисковой подсистемы и механизмы контрольных точек. При высоком hit ratio кэша, даже редкие физические чтения/записи создают эффект "бутылочного горлышка", вызывая массовое блокирование процессов и рост I/O wait. Система не успевает сбрасывать "грязные" страницы, что приводит к простою CPU.

Главный итог для OLAP: Нагрузка упирается в эффективность параллельных вычислений и синхронизации внутри самой СУБД (IPC, LWLocks). Низкий hit ratio кэша ожидаем для аналитики, но высокие накладные расходы на межпроцессное взаимодействие и легковесные блокировки не позволяют эффективно утилизировать CPU, превращая простои CPU в системные издержки.

Детальный сравнительный анализ статистических данных СУБД и инфраструктуры

Сформируй сводный сравнительный отчет по производительности СУБД и инфраструктуры:

Эксперимент-1(нагрузка имитирующая OLTP)

Эксперимент-2(нагрузка имитирующая OLAP)

Для формирования отчета используй списки, вместо таблиц.

Состав отчета:

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

# Общий анализ операционной скорости и ожиданий СУБД для "Эксперимент-1(нагрузка имитирующая OLTP)" и "Эксперимент-2(нагрузка имитирующая OLAP)"

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

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

## 1. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД

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

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

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

## 3. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД и МЕТРИК vmstat

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

## 4. СРАВНЕНИЕ ДИАГРАММ ПАРЕТО ПО WAIT_EVENT_TYPE и QUERYID

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

# Детальный анализ – граничные значения и корреляции для "Эксперимент-1(нагрузка имитирующая OLTP)" и "Эксперимент-2(нагрузка имитирующая OLAP)"

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

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

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

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

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

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

# Ключевые проблемы для "Эксперимент-1(нагрузка имитирующая OLTP)" и "Эксперимент-2(нагрузка имитирующая OLAP)"

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

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

# Итоговый анализ влияния типа нагрузки на производительность СУБД и инфраструктуры

Сводный сравнительный отчет: OLTP vs OLAP

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

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

Аппаратная платформа: Виртуальная машина (KVM) с 8 vCPU (Intel Xeon Skylake), 7.5 GB RAM

Дисковая подсистема: LVM на отдельных виртуальных дисках:

• /data (99 ГБ) для данных
• /wal (49 ГБ) для WAL
• /log (29 ГБ) для логов.

Ключевые настройки PostgreSQL:

• shared_buffers = 4GB
• work_mem = 128MB
• max_connections = 3000
• checkpoint_timeout = 5min, max_wal_size = 32GB
• synchronous_commit = on
• random_page_cost = 1.1
• effective_io_concurrency = 300

Настройки VM:

• vm.dirty_background_ratio = 5
• vm.dirty_ratio = 10
• vm.dirty_expire_centisecs = 3000
• vm.dirty_writeback_centisecs = 500
• vm.vfs_cache_pressure = 50
• vm.swappiness = 1

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

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

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

• OLTP: MIN=515 233, MEDIAN=541 160, MAX=586 100
• OLAP: MIN=120 831, MEDIAN=125 108, MAX=205 959

Вывод: Медианная скорость OLTP в 4,3 раза выше, чем OLAP. Разброс значений у OLAP больше (от min к max), что указывает на нестабильность.

Общие ожидания (WAITINGS):

• OLTP: MIN=24 269, MEDIAN=36 311, MAX=67 889
• OLAP: MIN=14 889, MEDIAN=22 810, MAX=35 584

Вывод: Абсолютное число ожиданий в OLTP выше, однако это связано с гораздо более высокой операционной скоростью. Отношение WAITINGS/SPEED у OLAP значительно хуже.

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

Тренд операционной скорости (R² / угол наклона):

• OLTP: R²=0.96 (очень высокое качество), угол = +44.46 (позитивный тренд)
• OLAP: R²=0.67 (хорошее), угол = +39.38 (позитивный тренд, но более пологий)

Вывод: В OLTP скорость растет стабильно и предсказуемо. В OLAP рост медленнее и модель менее точная.

Тренд общих ожиданий (R² / угол наклона):

• OLTP: R²=0.91 (очень высокое), угол = +43.58 (позитивный тренд – рост ожиданий вместе со скоростью)
• OLAP: R²=0.94 (очень высокое), угол = +44.12 (позитивный тренд – рост ожиданий)

Вывод: В обеих нагрузках ожидания растут синхронно со скоростью, что естественно. Однако в OLAP темп роста ожиданий опережает темп роста скорости.

Регрессия скорости по ожиданиям (R²):

• OLTP: R²=0.95 (очень высокое) – скорость сильно зависит от общего объема ожиданий.
• OLAP: R²=0.75 (хорошее) – зависимость менее жесткая, присутствуют другие факторы.

1. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД

Основной тип ожиданий по интегральному приоритету:

• OLTP: IO (0.6271) – КРИТИЧЕСКИЙ. Остальные типы (IPC, LWLock, Timeout) имеют приоритет <0.01 и игнорируются.
• OLAP: IPC (0.8482) – КРИТИЧЕСКИЙ, далее Timeout (0.5836), LWLock (0.4683), IO (0.3905). Все требуют внимания.

Вклад в общие ожидания:

• OLTP: 100% ожиданий практически полностью состоят из IO (поскольку другие типы имеют мизерные значения).
• OLAP: Структура сложная: IPC доминирует, но LWLock и Timeout также значимы, IO присутствует, но не является главным.

Качество моделей для типов ожиданий:

• OLTP: Модель для IO – R²=1.00 (идеальная).
• OLAP: Модели для IPC (R²=1.00), LWLock (R²=0.87), Timeout (R²=0.99), IO (R²=0.71) – от очень высоких до хороших. Все значимы.

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

• OLTP страдает исключительно от IO-ожиданий, остальные типы не играют роли. Это классическая картина для транзакционной нагрузки с узким местом в дисковой подсистеме.
• OLAP имеет комплексную проблему: основной вклад вносят ожидания межпроцессного взаимодействия (IPC) и легковесных блокировок (LWLock), а также тайм-аутов. IO отходит на второй план, что указывает на проблемы синхронизации и параллелизма внутри СУБД.

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

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

• OLTP: R²=0.01 (непригодная модель), тренд практически нулевой (0.04). Нагрузка на CPU стабильна.
• OLAP: R²=0.72 (хорошее), тренд +29.09 (негативный, сильный рост). Растет конкуренция за CPU.

procs b (процессы в uninterruptible sleep, ожидание IO):

• OLTP: R²=0.90 (очень высокое), тренд +39.16 (негативный, критический). Резкий рост числа процессов, заблокированных в ожидании IO.
• OLAP: R²=0.03 (непригодная модель), тренд -0.25 (незначим). Блокировки по IO не растут.

cpu wa (процент времени ожидания IO):

• OLTP: R²=0.93 (очень высокое), тренд +40.66 (негативный, критический). Время простоя CPU из-за IO стремительно увеличивается.
• OLAP: R²=0.90 (очень высокое), тренд -38.97 (позитивный). Доля wa снижается, что хорошо.

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

• OLTP: R²=0.92 (очень высокое), тренд -40.47 (негативный, критический). Простой CPU уменьшается, но не из-за полезной работы, а из-за роста wa.
• OLAP: R²=0.88 (очень высокое), тренд +38.05 (негативный). Простой CPU растет – парадокс, означающий, что CPU простаивает, не будучи загруженным ни полезной работой, ни ожиданием IO (скорее всего, из-за блокировок внутри СУБД).

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

• OLTP демонстрирует классическую картину IO-узкого места: взрывной рост b и wa при стабильной очереди на CPU. Система задыхается от ожидания диска.
• OLAP показывает противоположную динамику: падение wa, но рост r (очередь на CPU) и рост id (простой CPU). Это указывает на то, что процессы не могут получить доступ к разделяемым ресурсам (LWLock, IPC) и просто «висят», не утилизируя CPU.

3. СРАВНИТЕЛЬНЫЙ СТАТИСТИЧЕСКИЙ АНАЛИЗ ОЖИДАНИЙ СУБД И МЕТРИК VMSTAT

Корреляции главных типов ожиданий с метриками:

OLTP (IO):

• wa (ожидание IO): r=0.94 (очень высокая), R²=0.88.
• bi (блоки чтения): r=0.67, R²=0.45 (средняя).
• bo (блоки записи): корреляция отсутствует.

Вывод: IO-ожидания тесно связаны с простоями CPU из-за IO, но слабо коррелируют с объемом чтения и практически не связаны с записью. Вероятно, проблема в синхронных операциях (например, WAL-запись или чекпоинты).

OLAP (IPC):

• sy (system time): r=0.93, R²=0.87 (очень высокая).
• in (прерывания): r=0.89, R²=0.80.
• cs (переключения контекста): r=0.82, R²=0.68.

Вывод: IPC-ожидания напрямую связаны с работой ядра ОС (системные вызовы, прерывания, переключения контекста). Это указывает на интенсивное взаимодействие между процессами PostgreSQL.

Корреляции метрик vmstat между собой:

• OLTP: Очень высокие корреляции cs с in (r=0.98), cs с us (r=0.95). Высокая активность переключений контекста вызвана как прерываниями, так и пользовательской нагрузкой.
• OLAP: cs также сильно коррелирует с in (r=0.99) и с us (r=0.72), но связь с us слабее. Зато cs имеет хорошую связь с sy (r=0.69, R²=0.48). Это подтверждает, что системные вызовы играют большую роль.

Корреляции с dirty pages:

• OLTP: Размер dirty pages сильно коррелирует с wa (r=0.80, R²=0.64) и с b (r=0.92, R²=0.85). Это прямое указание на то, что накопление "грязных" страниц приводит к блокировкам процессов и росту I/O wait.
• OLAP: Dirty pages коррелируют с free (r=-0.84, R²=0.71) и bo (r=0.98, R²=0.96), но не с wa и b. То есть система генерирует dirty pages, они успешно сбрасываются (высокая корреляция с bo), но это не создает ожиданий – запись асинхронна и не блокирует процессы.

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

• OLTP – диск является узким местом: накопление dirty pages напрямую вызывает блокировки процессов (b) и рост I/O wait (wa). Корреляции с bo нет, значит, запись происходит не плавно, а всплесками (вероятно, чекпоинты).
• OLAP – проблемы лежат в области синхронизации процессов: IPC и LWLock тесно связаны с системным временем и прерываниями. Дисковая подсистема справляется, dirty pages сбрасываются без задержек. Процессы "соревнуются" за внутренние ресурсы СУБД.

4. СРАВНЕНИЕ ДИАГРАММ ПАРЕТО ПО WAIT_EVENT_TYPE И QUERYID

OLTP:

• Основной queryid: 1950630997716895623 (запрос select scenario1()).
• Вклад в ожидания: 84.9% всех IO-ожиданий приходятся на этот запрос.
• События: DataFileRead / DataFileWrite.
• Вывод: Узкое место локализовано в одном запросе (или сценарии). Оптимизация этого запроса (индексы, переписывание) может кардинально улучшить ситуацию.

OLAP:

• Основной queryid: 3551573579203076618 (запрос select scenario1()).
• Вклад в ожидания:
• IPC: 100%
• Timeout: 99.6%
• LWLock: 96.2%
• IO: 64.9% (остальные 35% у другого запроса)
• События: BufferIo, SpinDelay, SyncScan/BufferMapping/WALInsert/BufferContent/CheckpointerComm/pg_stat_statements, DataFileWrite/Read.
• Вывод: Один и тот же запрос генерирует практически все типы ожиданий. Это свидетельствует о том, что сценарий scenario1 в OLAP-нагрузке крайне неэффективен с точки зрения внутренней архитектуры PostgreSQL – он вызывает интенсивную конкуренцию за буферы, блокировки и межпроцессное взаимодействие.

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

В обоих экспериментах главный "виновник" – запрос select scenario1(). Однако характер проблем разный: в OLTP он вызывает чрезмерные IO-операции, в OLAP – порождает целый букет ожиданий, связанных с параллелизмом и синхронизацией.

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

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

OLTP:

• IO – мин/медиана/макс: 24 266 / 36 306 / 67 870 (почти совпадает с общими ожиданиями)
• Остальные типы – значения близки к нулю.

OLAP:

• IPC – медиана 17 412, макс 28 213.
• IO – медиана 5 128, макс 6 612 (в разы меньше, чем IPC).
• Timeout – медиана 137, макс 296.
• LWLock – медиана 134, макс 462.

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

Shared Buffers Hit Ratio:

• OLTP: мин 96.6%, медиана 96.7%, макс 97.3% – отлично.
• OLAP: мин 52.9%, медиана 58.9%, макс 69.7% – критически низко для большинства операций, характерно для full scan.

Свободная RAM (<5% времени):

• OLTP: 100% времени – свободной памяти почти нет (ALARM).
• OLAP: 100% времени – тоже ALARM.
• Вывод: В обоих случаях память используется полностью, что ожидаемо при 4GB shared_buffers из 7.5GB RAM. Однако hit ratio при этом в OLTP высокий – данные эффективно переиспользуются, а в OLAP – нет.

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

wa > 10% времени:

• OLTP: 100% времени (ALARM).
• OLAP: 90.9% времени (ALARM). Несмотря на падающий тренд, wa все еще очень высок.

b (процессы в uninterruptible sleep) превышение ядер CPU:

• OLTP: 26.4% времени (WARNING). Растет.
• OLAP: 0% времени (OK).

Корреляции с IO:

• OLTP: сильная связь IO с wa, слабая с bi, отсутствие с bo.
• OLAP: очень сильная связь IO с bo (r=0.95, R²=0.90), но не с wa. Это значит, что в OLAP запись на диск происходит асинхронно и не вызывает простоев CPU.

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

Переключения контекста (cs) и прерывания (in):

• OLTP: cs и in сильно коррелируют (r=0.98), также cs коррелирует с us (r=0.95) – пользовательская нагрузка генерирует переключения.
• OLAP: cs коррелирует с in (r=0.99) и с sy (r=0.69) – системные вызовы важнее.

system time (sy):

• OLTP: sy низкая (медиана 5%), корреляции с cs есть, но не ключевые.
• OLAP: sy немного выше (медиана 7%), но главное – очень высокие корреляции sy с IPC, LWLock, Timeout, dirty pages. Ядро тратит много времени на обслуживание внутренних механизмов PostgreSQL.

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

• OLTP: LWLock приоритет <0.01, игнорируется. Фактически отсутствуют.
• OLAP: LWLock приоритет 0.4683 (ВЫСОКИЙ). Сильная корреляция с sy (r=0.96, R²=0.93) и с cs (r=0.58, R²=0.34). Это указывает на конкуренцию за разделяемые структуры в памяти (буферный кэш, WAL и др.).

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

• OLTP: Один запрос (scenario1) вызывает 85% всех IO-ожиданий.
• OLAP: Тот же запрос (scenario1) является источником всех типов ожиданий: 100% IPC, 99.6% Timeout, 96% LWLock, 65% IO.

Ключевые проблемы для "Эксперимент-1 (OLTP)" и "Эксперимент-2 (OLAP)"

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

OLTP:

• Высокая зависимость производительности от IO (R²=0.95).
• Накопление dirty pages и, предположительно, резкие сбросы при чекпоинтах, вызывающие всплески ожиданий.
• Один проблемный запрос генерирует почти все IO-ожидания – возможно, неэффективное использование индексов или сканирования.

OLAP:

• Критический уровень ожиданий IPC и LWLock, указывающий на внутреннюю конкуренцию процессов.
• Очень низкий hit ratio буферного кэша – данные не помещаются в shared_buffers, но даже имеющиеся данные неэффективно используются из-за блокировок.
• Высокая корреляция ожиданий с системным временем – накладные расходы ядра на синхронизацию.

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

OLTP:

• Дисковая подсистема не справляется с пиковыми нагрузками записи (рост b и wa).
• Параметры vm.dirty_* (5%/10%) могут быть недостаточно агрессивными для данной нагрузки – накопление dirty pages приводит к блокировкам.
• Недостаточная пропускная способность IO для синхронной записи WAL и чекпоинтов.

OLAP:

• Несмотря на достаточную производительность диска (wa снижается, bo коррелирует с dirty pages), процессоры простаивают из-за внутренних блокировок СУБД.
• Возможно, не хватает процессорных ядер для эффективного параллельного выполнения сложных запросов, но проблема не в количестве, а в механизмах синхронизации.
• Параметры планировщика ОС (переключения контекста, прерывания) могут быть не оптимальны для интенсивного межпроцессного взаимодействия.

Итоговый анализ влияния типа нагрузки на производительность СУБД и инфраструктуры

Тип нагрузки определяет "узкое место":

• Для OLTP (много коротких транзакций) основным ограничителем становится дисковая подсистема. Даже при отличном hit ratio, синхронная запись WAL и чекпоинты создают пиковые нагрузки, вызывающие массовые ожидания и блокировки процессов. Система упирается в IOPS и пропускную способность диска.
• Для OLAP (сложные аналитические запросы) на первый план выходят механизмы внутренней синхронизации PostgreSQL. Низкий hit ratio ожидаем, но главная проблема – конкуренция за разделяемые ресурсы (буферы, WAL, вспомогательные процессы), что проявляется в росте ожиданий IPC и LWLock. CPU простаивает, ожидая доступа к данным в shared buffers, а не чтения с диска.

Разные пути оптимизации:

• OLTP требует ускорения диска (NVMe, отдельный диск для WAL), настройки контрольных точек (увеличение checkpoint_timeout и max_wal_size для сглаживания пиков), возможно, уменьшения synchronous_commit или использования группы коммитов (commit_delay). Также критична оптимизация проблемного запроса.
• OLAP требует настройки параллелизма (max_parallel_workers_per_gather, max_parallel_workers), возможно, увеличения shared_buffers (если позволяет RAM), а также более глубокого анализа конкуренции за конкретные LWLock (буферные отображения, WAL insert). Иногда помогает партиционирование таблиц или использование представлений MATERIALIZED VIEW. Также важно проверить настройки планировщика ОС для уменьшения накладных расходов на переключение контекста.

Общая инфраструктурная проблема

В обоих случаях наблюдается нехватка свободной RAM (100% времени менее 5% свободной памяти). Хотя для OLAP это может быть допустимо (активное использование файлового кэша), для OLTP это риск вытеснения важных страниц. Рекомендуется либо увеличить RAM, либо уменьшить shared_buffers (если файловый кэш эффективнее), но это требует дополнительных экспериментов.

Таким образом, характер нагрузки радикально меняет фокус расследования и вектор оптимизации: от "железной" дисковой подсистемы к "программной" архитектуре СУБД.

Послесловие

Предложенная связка инструментов — pg_expecto для статистической обработки данных и DeepSeek для формирования итоговых отчетов по промптам — позволяет стандартизировать процесс анализа нагрузочного тестирования.

В итоге получена готовая методика:

1. Прогнали нагрузку
2. Статистически обработали метрики
3. Передали промпты LLM
4. На выходе имеем структурированный сравнительный отчет.