VPS для PostgreSQL: установка и тюнинг под нагрузку

PostgreSQL — самая популярная открытая СУБД для серьёзных проектов. Разберём установку из официального репозитория, базовый тюнинг под объём памяти, безопасный доступ по сети и первый бэкап. Всё рабочими командами для Ubuntu.

Почему PostgreSQL требователен к диску

PostgreSQL — транзакционная СУБД, и почти каждая запись сопровождается синхронной записью в WAL (журнал упреждающей записи). Скорость этих fsync напрямую определяет, сколько транзакций в секунду вы получите. На медленном диске сервер упирается в I/O задолго до того, как закончится CPU.

Именно поэтому для базы критичны не гигагерцы, а IOPS и латентность диска. На SATA-SSD и тем более на сетевых томах задержка fsync легко становится узким местом. NVMe даёт на порядок больше операций в секунду и низкую задержку — база дышит свободно.

• WAL и fsync — каждый commit пишет на диск, важна латентность.
• IOPS важнее частоты CPU — база чаще ждёт диск, чем считает.
• RAM под кэш — горячие страницы должны жить в памяти.

Установка из официального репозитория

В репозитории Ubuntu часто устаревшая версия. Подключим официальный APT-репозиторий PostgreSQL и поставим свежую мажорную версию (например 16).

sudo apt update && sudo apt install -y curl ca-certificates
sudo install -d /usr/share/postgresql-common/pgdg
curl -fsSL https://www.postgresql.org/media/keys/ACCC4CF8.asc | \
  sudo gpg --dearmor -o /usr/share/postgresql-common/pgdg/apt.postgresql.org.gpg
echo "deb [signed-by=/usr/share/postgresql-common/pgdg/apt.postgresql.org.gpg] https://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" | \
  sudo tee /etc/apt/sources.list.d/pgdg.list
sudo apt update && sudo apt install -y postgresql-16

Проверим, что сервис поднялся, и зайдём в psql под системным пользователем postgres:

sudo systemctl status postgresql
sudo -u postgres psql -c "SELECT version();"

Создание базы и пользователя

Не работайте под суперпользователем postgres из приложения. Заведём отдельную роль и базу под проект, выдав права только на неё.

sudo -u postgres psql <<'SQL'
CREATE ROLE appuser WITH LOGIN PASSWORD 'strong_password_here';
CREATE DATABASE appdb OWNER appuser;
GRANT ALL PRIVILEGES ON DATABASE appdb TO appuser;
SQL

Проверить подключение новой ролью можно так — пароль запросит интерактивно:

psql -h 127.0.0.1 -U appuser -d appdb -W

Базовый тюнинг под объём RAM

Дефолтный конфиг PostgreSQL рассчитан на слабое железо и почти всегда недоиспользует память. Основные параметры правятся в postgresql.conf. Ориентиры для сервера с 4 ГБ RAM под выделенную БД:

# /etc/postgresql/16/main/postgresql.conf
shared_buffers = 1GB           # ~25% RAM
effective_cache_size = 3GB      # ~75% RAM, подсказка планировщику
work_mem = 32MB                 # на операцию сортировки/хеша
maintenance_work_mem = 256MB    # для VACUUM и CREATE INDEX
wal_buffers = 16MB
max_connections = 100
random_page_cost = 1.1          # для SSD/NVMe, а не 4.0 как для HDD

Параметр random_page_cost = 1.1 особенно важен на NVMe: он говорит планировщику, что случайное чтение почти так же дёшево, как последовательное, и тот охотнее использует индексы. После правок перезапускаем сервер.

sudo systemctl restart postgresql

Не завышайте work_mem бездумно: он выделяется на каждую сортировку каждого соединения, поэтому пиковое потребление = work_mem × число параллельных операций. При 100 коннектах агрессивный work_mem легко приводит к OOM.

Доступ по сети и автовакуум

По умолчанию PostgreSQL слушает только localhost — это безопасно. Если к базе ходит приложение с другого сервера, откройте прослушивание и явно разрешите подсеть в pg_hba.conf, не открывая базу всему интернету.

# postgresql.conf
listen_addresses = 'localhost,10.0.0.5'

# pg_hba.conf — доступ только из доверенной подсети по паролю
host    appdb    appuser    10.0.0.0/24    scram-sha-256

Автовакуум держит таблицы в форме, убирая мёртвые строки после UPDATE/DELETE. Выключать его нельзя, но под нагрузкой полезно сделать агрессивнее, чтобы не пухли таблицы и не тормозили запросы.

# postgresql.conf
autovacuum = on
autovacuum_vacuum_scale_factor = 0.05
autovacuum_naptime = 30s

Бэкап и выбор сервера

Логический бэкап всей базы делается pg_dump — его удобно класть в крон. Для восстановления просто прогоняете дамп обратно через psql.

# бэкап со сжатием
pg_dump -U appuser -Fc appdb > /var/backups/appdb_$(date +%F).dump
# восстановление
pg_restore -U appuser -d appdb --clean /var/backups/appdb_2026-01-01.dump

Под PostgreSQL берите сервер с быстрым диском: производительность БД почти всегда упирается в I/O. На тарифах MAATRIX это AMD EPYC + NVMe — высокие IOPS и низкая латентность fsync дают ощутимо больше транзакций в секунду, чем сетевые тома у многих провайдеров. Ежедневные бэкапы MAATRIX страхуют данные, локации UK/США/РФ дают низкий пинг, а оплата картой РФ, СБП, криптой или токеном MAAT удобна, когда зарубежные хостеры карты не принимают.

• Дефолтный конфиг — база не видит вашу RAM, работает медленно.
• Доступ 0.0.0.0/0 в pg_hba — база открыта всему интернету, брутфорс паролей.
• Отключённый автовакуум — распухание таблиц и деградация скорости.

Частые вопросы