Представь, что твой PostgreSQL работает как есть — он жив, но неэффективен. Ты платишь за ресурсы, которые не используешь, или сталкиваешься с тормозами под нагрузкой. Всё потому, что сердце СУБД — файл конфигурации postgresql.conf — настроено по умолчанию. Давай разберем, как превратить его из «работающего» в «летающего», и заодно подружим с его напарником — файлом pg_hba.conf, который отвечает за безопасность подключений.
Где живут файлы настроек PostgreSQL?
Первым делом нужно найти эти файлы. Расположение зависит от ОС и способа установки.
# Самый простой способ узнать путь — спросить у 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.conf иногда достаточно перечитать конфигурацию командой SELECT pg_reload_conf(); в psql.
Структура и работа с файлом postgresql.conf
Это основной файл конфигурации. Он определяет, сколько памяти будет использовать сервер, как вести журналирование, настраивает репликацию и сотни других параметров.
Формат файла и основные секции
Файл состоит из пар «параметр = значение». Символ # обозначает комментарий.
# -----------------------------
# 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.
# Память
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. Он определяет, КТО, ОТКУДА и К КАКОЙ БАЗЕ может подключиться, и КАК должен аутентифицироваться.
Синтаксис и примеры правил
Каждая строка — это правило. Формат: тип_подключения база_данных пользователь адрес метод_аутентификации [опции].
# 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С
# Для сервера с 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.
# Разрешаем подключение серверу 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: Резервное копирование и анализ текущей конфигурации
# Создаем бэкапы
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 или любой текстовый редактор. Рекомендую не редактировать исходный файл напрямую, а создать файл с переопределениями.
# В конце 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: Применение изменений и тестирование
# Перезагружаем конфигурацию (без перезапуска сервиса)
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 не имеет встроенной утилиты проверки, но можно использовать трюк:
# Запускаем 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). Это упрощает управление и версионирование.
# В конце основного 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С на виртуальной машине и для высоконагруженного кластера аналитики будут радикально отличаться.
Главное правило: меняй по одному-два параметра за раз, тестируй нагрузку и смотри на результат. И никогда не забывай про бэкапы конфигурационных файлов перед внесением изменений.