На основе методологии и результатов, представленных в статье "PG_EXPECTO: Анализ влияния размера shared_buffers на производительность СУБД PostgreSQL", можно сформулировать и обосновать следующую гипотезу:

Классическая эмпирическая рекомендация "shared_buffers = 25% от объёма оперативной памяти" не подтверждается строгим экспериментом и может считаться научно необоснованной. Основная причина снижения производительности СУБД PostgreSQL при высоком значении hit ratio (доли чтений из кэша) связана с увеличением нагрузки на процессор (CPU) для управления большим буферным пулом и конкуренцией за доступ к данным в памяти, а не с гипотетическими "накладными расходами" на обслуживание самого shared_buffers.

 Доказательство на основе методологии и результатов PG_EXPECTO

1.Опровержение универсального правила "25% RAM"

• Контекст правила: Это эмпирическое правило родилось в эпоху, когда объем оперативной памяти сервера измерялся гигабайтами, а ядра процессора были одно- или двухъядерными. Оно было призвано предотвратить вытеснение из памяти кэша операционной системы и избежать двойного кэширования.

• Данные эксперимента PG_EXPECTO: Статья демонстрирует, что производительность продолжает расти даже после превышения порога в 25% от доступной RAM для определенных типов нагрузок (например, для сценариев, где размер рабочего набора данных близок к объему памяти). Кривая производительности не показывает резкого "обрыва" или падения в этой точке. Оптимальное значение определяется не процентом от RAM, а характером рабочей нагрузки и конфигурацией всей системы.

• Вывод: Правило "25%" не является научным законом, а грубым ориентиром для начальной настройки в условиях недостатка данных. PG_EXPECTO показывает, что только нагрузочное тестирование конкретной СУБД на конкретном железе с конкретными запросами даёт истинный оптимум.

2.Идентификация реальной причины снижения производительности — нагрузка на CPU

• Ожидаемое поведение vs. Реальность: Согласно устаревшему мнению, слишком большой shared_buffers должен создавать "накладные расходы" на управление. Однако статья, позволяет увидеть иную картину.

• Анализ производительности: Физические чтения с диска (shared read) практически исчезают. Логично ожидать, что производительность будет линейно расти, но этого не происходит. Рост замедляется, а в сценариях с высокой конкурентностью (22 сессии) может начаться деградация.

• Смещение узкого места: PG_EXPECTO позволяет зафиксировать, что узкое место смещается с подсистемы ввода-вывода (I/O) на центральный процессор (CPU). При отсутствии I/O-ожиданий основным потребителем времени становится:

  • Поиск и блокировки в памяти: Конкуренция (latch contention) за доступ к хэш-таблице буферного кэша и буферам данных.

  • Потребление CPU планировщиком: Обработка самих запросов, которым теперь не нужно ждать данные с диска.

• Ключевое доказательство: Если бы проблема была в "накладных расходах на обслуживание буфера", мы бы видели рост накладных издержек в самой СУБД. Однако производительность упирается в 100% утилизацию ядер CPU, что чётко отслеживается средствами мониторинга ОС (vmstat).

Практический вывод

Гипотеза подтверждается методологией PG_EXPECTO, которая заменяет мифы измеряемыми данными.

1. Рекомендация "25% RAM" — не догма. Она должна быть отправной точкой, а не финальной настройкой. Оптимум может находиться как ниже, так и значительно выше этого значения.

2. Главный враг при настройке shared_buffers — не абстрактные "накладные расходы", а реальная нехватка ресурсов CPU и конкуренция за доступ к памяти. После устранения I/O как узкого места, именно процессор становится лимитирующим фактором.

3. Стратегия настройки должна быть итеративной: Увеличивайте shared_buffers мониторя не только hit ratio, но и нагрузку на CPU, время отклика и конкуренцию . Эксперимент останавливается не когда достигнут некий магический процент, а когда прирост производительности становится незначительным или начинает падать из-за нехватки других ресурсов (CPU, memory).

Таким образом, PG_EXPECTO не просто анализирует один параметр, а демонстрирует системный подход: изменение одного ресурса (памяти) выявляет ограничения в другом (CPU), что и является признаком научно обоснованной настройки производительности.