PostgreSQL на 4 ГБ RAM: что настроить в первую очередь

PostgreSQL 16 на сервере с 4 ГБ RAM можно настроить так, чтобы он не отбирал всю память у Linux и не упирался в нехватку ресурсов при нескольких тяжёлых запросах. Ниже — отправная точка для двух сценариев: база работает отдельно или делит память с приложением. Значения нужно проверить под нагрузкой: одна настройка, подходящая небольшому сайту, может вызвать нехватку памяти при аналитических запросах.

Сначала определите, кому достанутся 4 ГБ

Считайте не только память, выделенную PostgreSQL. В общий лимит входят операционная система, приложение, фоновые процессы и, если вы используете контейнеры, остальные процессы в том же лимите cgroup. Оставьте системе резерв: если отдать базе почти всю память, Linux начнёт вытеснять страницы в swap или завершит процесс из-за нехватки памяти.

Перед настройкой зафиксируйте три вещи:

• 4 ГБ — это память всего сервера или лимит контейнера PostgreSQL;
• работает ли приложение на этом же сервере и сколько памяти ему нужно;
• сколько запросов реально выполняется одновременно, а не сколько подключений числится открытыми.

Профили ниже — начальные ориентиры для PostgreSQL 16 на Linux, а не расчёт для любой нагрузки. В первом предполагается, что сервер выделен под базу. Во втором часть памяти занята приложением или другими службами. Если фактический лимит контейнера меньше объёма RAM хоста, ориентируйтесь на лимит контейнера.

Настройки, которые влияют на память

shared_buffers — общий кеш PostgreSQL

Это память, которую сервер выделяет под кеш страниц базы. Для отдельного PostgreSQL-сервера с 4 ГБ RAM начните с 1 ГБ. Если рядом работает приложение, разумнее испытать 512 МБ. Увеличение не гарантирует ускорения: Linux тоже использует свободную память для кеширования файлов, а большой shared_buffers оставляет меньше места процессам запросов.

work_mem — не общий лимит на сервер

work_mem используется отдельными операциями запроса, например сортировкой или хешированием. Один запрос может создать несколько таких операций, а несколько запросов идут параллельно. Поэтому 64 МБ work_mem — не «всего 64 МБ на соединение»: реальное потребление может быть выше в разы. На машине с 4 ГБ начните с 2–4 МБ, а повышайте значение только для конкретных запросов после проверки плана и памяти.

effective_cache_size — подсказка планировщику

Этот параметр не резервирует память. Он помогает планировщику оценивать, какая часть данных может оказаться в кеше PostgreSQL и операционной системы. Для выделенного сервера можно начать с 2 ГБ, для общей машины — с 1 ГБ. Не ставьте сюда все 4 ГБ: операционная система и другие процессы тоже используют память.

Память на обслуживание и подключения

maintenance_work_mem задаёт лимит для обслуживающих операций, например создания индекса. Он не равен постоянному расходу памяти, но слишком большое значение опасно, если такие операции запускаются одновременно. Для autovacuum отдельно задайте autovacuum_work_mem: иначе рабочие процессы обслуживания могут опираться на maintenance_work_mem. А max_connections ограничивайте исходя из архитектуры приложения: каждое активное подключение повышает потенциальную нагрузку, особенно когда запросы используют work_mem.

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

Два стартовых профиля

Значения в таблице — не гарантия, что сервер выдержит конкретную нагрузку. Это безопасная отправная точка для измерений. Проверьте, что приложение укладывается в заданное число подключений; при использовании пула укажите его реальный размер.

Пример блока для отдельного сервера PostgreSQL 16. Внесите параметры в конфигурацию, которую действительно использует ваш экземпляр: путь зависит от способа установки и упаковки. Перед перезапуском проверьте конфигурацию средствами вашей версии и окружения.

shared_buffers = 1GB
effective_cache_size = 2GB
work_mem = 4MB
maintenance_work_mem = 256MB
autovacuum_work_mem = 64MB
max_connections = 30
max_parallel_workers_per_gather = 1

Если база делит 4 ГБ с приложением, используйте второй столбец таблицы как более осторожный старт. Не копируйте оба профиля одновременно: выберите один и меняйте по одному параметру, иначе не поймёте, что повлияло на результат.

Что измерить до и после

Сравнивайте одинаковые сценарии: тот же набор запросов, похожее число одновременных пользователей и сопоставимое состояние кеша. Запишите задержку запросов, загрузку CPU, свободную и доступную память ОС, использование swap, а также признаки завершения процессов из-за нехватки памяти. Для PostgreSQL проверьте, не растут ли временные файлы и не отстаёт ли autovacuum.

Если запросы замедляются, посмотрите их планы и выясните, где возникают сортировки или хеширование. Повышение work_mem может убрать часть временных операций с диска, но при параллельных запросах одновременно увеличить потребление RAM. Сначала попробуйте поднять его только для проблемного сеанса или запроса, а не для всего сервера.

Где эта настройка ломается

• Взяли 4 ГБ у хоста, хотя контейнеру доступно меньше. PostgreSQL может быть остановлен системой даже при наличии свободной памяти на физической машине. Проверяйте именно лимит контейнера и журналы окружения.
• Увеличили work_mem для всех. Под нагрузкой несколько подключений выполняют несколько операций с памятью каждое. Уменьшите значение и отдельно проверьте проблемный запрос.
• Поставили max_connections по числу пользователей. Не каждый посетитель должен держать отдельное соединение с базой. Сверьте настройки пула, число процессов приложения и предел сервера.
• Подняли shared_buffers, потому что «кеша мало». Сначала выясните, действительно ли запросы читают данные с медленного хранилища и не упираются ли они в CPU, блокировки или неоптимальный план.

Профиль с 4 ГБ не спасёт, если запросы читают лишние строки, приложение создаёт слишком много соединений или autovacuum не успевает обслуживать таблицы. Инвалидация кеша и настройка хранения WAL — отдельные темы; здесь рассматривается только базовый бюджет оперативной памяти.

Что делать дальше

Начните со второго, более осторожного профиля, если сервер не выделен только под базу. Зафиксируйте исходные показатели, примените настройки и прогоните обычный для вашего приложения сценарий вместе с пиковым. Если память заканчивается — сначала найдите процесс и операцию, которые её потребляют; если тормозят отдельные запросы — изучите их планы, прежде чем увеличивать work_mem. Настройки, требующие перезапуска, применяйте в запланированное окно, а после перезапуска проверьте, что PostgreSQL загрузил нужные значения.

Термин: cgroup — механизм Linux, который ограничивает ресурсы группы процессов. Для контейнера лимит cgroup может быть важнее объёма оперативной памяти всего хоста.