Настройка postgresql.conf и pg_hba.conf: полное руководство для DevOps | AdminWiki

Полное руководство по настройке postgresql.conf: от основ до оптимизации для 1С

17 декабря 2025 9 мин. чтения #1с #devops #pg_hba.conf #postgresql #postgresql.conf #базы данных #настройка
Содержание статьи

Представь, что твой PostgreSQL работает как есть — он жив, но неэффективен. Ты платишь за ресурсы, которые не используешь, или сталкиваешься с тормозами под нагрузкой. Всё потому, что сердце СУБД — файл конфигурации postgresql.conf — настроено по умолчанию. Давай разберем, как превратить его из «работающего» в «летающего», и заодно подружим с его напарником — файлом pg_hba.conf, который отвечает за безопасность подключений.

Где живут файлы настроек PostgreSQL?

Первым делом нужно найти эти файлы. Расположение зависит от ОС и способа установки.

bash
# Самый простой способ узнать путь — спросить у PostgreSQL
psql -U postgres -c "SHOW config_file;"
psql -U postgres -c "SHOW hba_file;"

# Типичные пути в Linux:
# /var/lib/pgsql/data/postgresql.conf
# /etc/postgresql/14/main/postgresql.conf
# /usr/local/var/postgres/postgresql.conf

# В Windows (при установке через installer):
# C:\Program Files\PostgreSQL\14\data\postgresql.conf
Важно: После изменения любого из этих файлов требуется перезагрузка сервиса PostgreSQL. Для postgresql.conf иногда достаточно перечитать конфигурацию командой SELECT pg_reload_conf(); в psql.

Структура и работа с файлом postgresql.conf

Это основной файл конфигурации. Он определяет, сколько памяти будет использовать сервер, как вести журналирование, настраивает репликацию и сотни других параметров.

Формат файла и основные секции

Файл состоит из пар «параметр = значение». Символ # обозначает комментарий.

config
# -----------------------------
# CONNECTIONS AND AUTHENTICATION
# -----------------------------
listen_addresses = 'localhost'          # Какие адреса слушать
port = 5432                             # Порт по умолчанию
max_connections = 100                   # Максимальное число подключений

# -----------------------------
# RESOURCE USAGE
# -----------------------------
shared_buffers = 128MB                  # Память, выделяемая для кэширования
work_mem = 4MB                          # Память на операцию сортировки/хеширования
maintenance_work_mem = 64MB             # Память для операций обслуживания (VACUUM, CREATE INDEX)

Критически важные настройки для производительности

Давай настроим параметры, которые дадут максимальный прирост «на старте». Предположим, у нас сервер с 8 ГБ RAM.

config
# Память
shared_buffers = 2GB                    # 25% от RAM. Кэш данных в памяти PostgreSQL.
work_mem = 10MB                         # Увеличиваем для сложных запросов с сортировкой.
maintenance_work_mem = 512MB            # Ускоряет VACUUM и перестроение индексов.
effective_cache_size = 6GB              # Оценка размера кэша ОС+PostgreSQL для планировщика.

# Write-Ahead Log (WAL) - журнал транзакций
wal_buffers = 16MB                      # Память под буфер WAL.
max_wal_size = 2GB                      # Макс. размер WAL сегментов перед checkpoint.
min_wal_size = 1GB                      # Мин. размер для удержания.

# Проверка целостности (Checkpoint)
checkpoint_completion_target = 0.9      # Растягиваем checkpoint, чтобы снизить пиковую нагрузку на диск.
Осторожно: Не копируй настройки слепо! shared_buffers на Windows редко стоит ставить больше 512 МБ из-за архитектуры памяти. Всегда тестируй изменения на staging-окружении.

Настройка файла pg_hba.conf для управления доступом

Файл pg_hba.conf (Host-Based Authentication) — это брандмауэр PostgreSQL. Он определяет, КТО, ОТКУДА и К КАКОЙ БАЗЕ может подключиться, и КАК должен аутентифицироваться.

Синтаксис и примеры правил

Каждая строка — это правило. Формат: тип_подключения база_данных пользователь адрес метод_аутентификации [опции].

config
# TYPE  DATABASE        USER            ADDRESS                 METHOD
# =====  =============  ==============  ======================  =========
# Разрешить локальные подключения через Unix-сокет для всех пользователей к всем БД
local   all             all                                     trust

# Разрешить подключение с localhost (TCP/IP) для пользователя postgres ко всем БД с паролем
host    all             postgres        127.0.0.1/32            scram-sha-256

# Разрешить подключение пользователю app_user из сети 192.168.1.0/24 только к БД app_db
host    app_db          app_user        192.168.1.0/24          scram-sha-256

# Разрешить подключение из любой точки (0.0.0.0/0) для репликации
host    replication     replicator      0.0.0.0/0               scram-sha-256

# Запретить всё остальное (эта строка должна быть ПОСЛЕДНЕЙ!)
host    all             all             0.0.0.0/0               reject

Методы аутентификации (METHOD)

Метод Описание Безопасность Использование
trust Подключение без пароля Очень низкая Только для localhost в dev-среде
md5 Аутентификация по хешу MD5 Устаревшая Для старых клиентов
scram-sha-256 Современный метод с солью Высокая (рекомендуется) Для всех новых проектов
reject Явный запрет подключения - Для блокировки нежелательных сетей

Особенности настройки PostgreSQL для 1С

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

Ключевые параметры postgresql.conf для 1С

config
# Для сервера с 16+ ГБ RAM под 1С
max_connections = 200                   # 1С любит много одновременных сессий
shared_buffers = 4GB                    # Увеличиваем кэш
work_mem = 16MB                         
maintenance_work_mem = 1GB

# Критически важно для 1С!
effective_io_concurrency = 2           # Для HDD. Для SSD можно 200-300.
random_page_cost = 2.0                  # Понижаем для SSD (1.1-1.5). Снижает стоимость случайного чтения.

# Управление версиями строк (MVCC) и очисткой (VACUUM)
autovacuum_vacuum_scale_factor = 0.05  # Запускать autovacuum при 5% изменений (вместо 20% по умолчанию).
autovacuum_analyze_scale_factor = 0.02 # Чаще обновлять статистику.
autovacuum_max_workers = 3             # Больше воркеров для параллельной очистки.

# Планировщик запросов
default_statistics_target = 500        # Увеличиваем сбор статистики для сложных запросов 1С.

Настройка pg_hba.conf для инфраструктуры 1С

Типичная схема: сервер 1С-приложения подключается к кластеру PostgreSQL.

config
# Разрешаем подключение серверу 1С (например, с IP 192.168.10.50)
host    all             "1c_application"  192.168.10.50/32    scram-sha-256

# Разрешаем подключение администраторам для обслуживания
host    all             postgres         192.168.10.0/24     scram-sha-256

# Всё остальное запрещаем
host    all             all             0.0.0.0/0           reject

Практическое пошаговое руководство по настройке

Шаг 1: Резервное копирование и анализ текущей конфигурации

bash
# Создаем бэкапы
cp /path/to/postgresql.conf /path/to/postgresql.conf.backup_$(date +%Y%m%d)
cp /path/to/pg_hba.conf /path/to/pg_hba.conf.backup_$(date +%Y%m%d)

# Смотрим текущие настройки (можно выполнить в psql)
psql -U postgres -c "SELECT name, setting, unit FROM pg_settings WHERE name IN ('shared_buffers', 'work_mem', 'max_connections');"

Шаг 2: Редактирование файлов

Используй vim, nano или любой текстовый редактор. Рекомендую не редактировать исходный файл напрямую, а создать файл с переопределениями.

bash
# В конце postgresql.conf добавляем строку:
# include_if_exists = 'postgresql.conf.local'

# Затем создаем файл с нашими настройками
echo "# Custom settings" > /path/to/data/postgresql.conf.local
echo "shared_buffers = '2GB'" >> /path/to/data/postgresql.conf.local
echo "work_mem = '16MB'" >> /path/to/data/postgresql.conf.local
# ... и так далее

Шаг 3: Применение изменений и тестирование

bash
# Перезагружаем конфигурацию (без перезапуска сервиса)
psql -U postgres -c "SELECT pg_reload_conf();"

# ИЛИ перезапускаем сервис (если меняли pg_hba.conf или критические параметры)
sudo systemctl restart postgresql-14  # Или postgresql.service

# Проверяем, что настройки применились
psql -U postgres -c "SELECT name, setting FROM pg_settings WHERE source = 'configuration file' AND sourcefile LIKE '%local%';"

Часто задаваемые вопросы (FAQ)

Как проверить синтаксис postgresql.conf перед перезагрузкой?

PostgreSQL не имеет встроенной утилиты проверки, но можно использовать трюк:

bash
# Запускаем postgres в режиме проверки конфига (не запуская сервер)
/usr/lib/postgresql/14/bin/postgres -D /path/to/data --config-file=/path/to/postgresql.conf --check

Почему изменения в pg_hba.conf не применяются после pg_reload_conf()?

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

Какие настройки postgresql.conf наиболее критичны для производительности OLTP-нагрузки (как у 1С)?

  • shared_buffers: Кэш данных. Слишком малый — постоянный disk I/O, слишком большой — может конфликтовать с кэшем ОС.
  • work_mem: Влияет на скорость сортировки и хеш-соединений. Недостаток ведет к записи на диск (temp files).
  • autovacuum параметры: 1С активно изменяет данные. Без своевременного VACUUM база «распухнет» и замедлится.
  • random_page_cost и effective_io_concurrency: Правильные значения для твоего типа диска (HDD/SSD) кардинально меняют план выполнения запросов.

Можно ли хранить настройки вне стандартного файла postgresql.conf?

Да, и это лучшая практика! Используй директиву include или include_if_exists в основном файле, чтобы подключать дополнительные файлы (например, memory.conf, replication.conf). Это упрощает управление и версионирование.

config
# В конце основного postgresql.conf:
include_if_exists = 'conf.d/memory_settings.conf'
include_if_exists = 'conf.d/autovacuum_settings.conf'
include_if_exists = 'conf.d/replication_settings.conf'

Заключение

Настройка postgresql.conf и pg_hba.conf — это не разовое действие, а итерационный процесс. Начни с базовых параметров, описанных выше, затем мониторь производительность с помощью pg_stat_statements и системных метрик. Помни, что не существует «волшебного» конфига на все случаи жизни. Настройки для маленькой базы 1С на виртуальной машине и для высоконагруженного кластера аналитики будут радикально отличаться.

Главное правило: меняй по одному-два параметра за раз, тестируй нагрузку и смотри на результат. И никогда не забывай про бэкапы конфигурационных файлов перед внесением изменений.

Поделиться:
Сохранить гайд? В закладки браузера