Проблема
PostgreSQL по умолчанию устанавливается с очень консервативными настройками, ориентированными на работу в системах с минимальным объёмом оперативной памяти около 512 МБ или даже меньше. Такой подход гарантирует, что сервер баз данных запустится практически на любом оборудовании, однако совершенно не подходит для продуктивной эксплуатации, особенно в связке с платформой «1С:Предприятие». На сервере с десятками гигабайт ОЗУ и быстрым NVMe-диском база данных внезапно начинает «тормозить»: запросы выполняются медленно, блокировки растут, а мониторинг показывает высокий %util на дисках. Причина почти всегда кроется в том, что администратор не адаптировал параметры конфигурации postgresql.conf под реальное «железо». PostgreSQL настройка производительности это обязательный этап, без которого невозможно получить стабильно высокую скорость работы, будь то обслуживание сотен пользователей 1С или нагруженного веб-приложения.
Решение
Применим методику расчёта основных параметров на основе объёма оперативной памяти сервера. Этот подход задокументирован в официальном руководстве PostgreSQL Configuration и в рекомендациях компании Postgres Professional для высоконагруженных систем Настройка PostgreSQL для 1С. Дополнительно учтём требования «1С:Предприятие» к СУБД, описанные на сайте its.1c.ru. Настроим три группы параметров: память, планировщик и ввод-вывод. Все команды выполняются на сервере под управлением Linux (Debian/Ubuntu/Astra Linux) с PostgreSQL версии 14, 15 или 16. После изменения конфигурации обязательно протестируем производительность с помощью pgbench.
Пошаговая инструкция
Шаг 1. Определение доступного объёма памяти
Прежде чем править конфигурацию, необходимо понять, сколько ОЗУ можно выделить PostgreSQL. Общее правило: для выделенного сервера баз данных PostgreSQL отдают до 70% физической памяти, оставляя остальное под страничный кеш ОС и служебные нужды. Если на сервере работает ещё и платформа 1С (сервер приложений), долю снижают до 50%.
bash
free -hПример: общий объём ОЗУ — 32 ГБ. Под PostgreSQL выделим 22 ГБ (70%).
Шаг 2. Базовые параметры памяти
Откройте файл postgresql.conf (обычно /etc/postgresql/16/main/postgresql.conf) и задайте значения.
shared_buffers — кеш страниц данных, аналог буферного кеша Oracle. Главное правило для начала: 25% от доступной ОЗУ.
shared_buffers = 8GBeffective_cache_size оценка объёма страничного кеша ОС плюс shared_buffers. Не выделяет память, но планировщик использует её для выбора оптимального плана запроса. Рекомендуется 50–75% от ОЗУ.
effective_cache_size = 16GBwork_mem память, выделяемая для сортировки и хеш-таблиц на каждую операцию в рамках одного запроса. Ошибка новичков установить слишком большим. Расчёт: (ОЗУ - shared_buffers) / (max_connections * 4). Для 1С типично 150–200 подключений.
work_mem = 64MBmaintenance_work_mem память для служебных операций: VACUUM, CREATE INDEX, REINDEX. Можно установить большим, так как эти операции редки и выполняются последовательно.
maintenance_work_mem = 1GBtemp_buffers кеш временных таблиц. Обычно 8-16 МБ достаточно.
temp_buffers = 16MBОфициальная документация по этим параметрам: PostgreSQL Memory Configuration.
Шаг 3. Параметры планировщика запросов
random_page_cost — стоимость произвольного чтения страницы с диска по отношению к последовательному. Для SSD (NVMe/SATA) значение нужно снижать до 1.1–1.5, иначе планировщик будет избегать индексов, считая диск медленным.
random_page_cost = 1.1seq_page_cost и cpu_tuple_cost обычно оставляют по умолчанию (1.0 и 0.01 соответственно), если только вы не работаете с очень специфичными нагрузками.
effective_io_concurrency — количество одновременных операций ввода-вывода, которые может обслужить дисковая подсистема. Для NVMe -200, для SATA SSD — 100, для HDD — 2.
effective_io_concurrency = 200Полный список параметров планировщика и их описание: Planner Cost Constants.
Шаг 4. Настройка ввода-вывода и WAL
wal_level — для продакшена рекомендуем replica (или logical, если нужна логическая репликация). Это влияет на объём записываемых данных.
wal_level = replicafsync — принудительный сброс WAL на диск. Отключать (off) можно только в тестовых средах, иначе при сбое питания возможна потеря данных.
fsync = onsynchronous_commit для высокой производительности при нагрузке 1С часто устанавливают off, что не нарушает целостности данных, но может привести к потере последних транзакций при аварийном выключении сервера. Безопасное значение on, компромиссное remote_write (если есть реплика).
synchronous_commit = onwal_buffers обычно 1/32 от shared_buffers, но не более 16 МБ.
wal_buffers = 16MBmax_wal_size и min_wal_size — предельные размеры кластера журналов WAL. Для активной записи увеличьте max_wal_size.
max_wal_size = 4GB
min_wal_size = 1GBПодробнее: Write Ahead Log Configuration.
Шаг 5. Специфические настройки для 1С:Предприятие
Платформа 1С активно использует временные таблицы и выполняет множество однотипных запросов с параметрами. Рекомендуется:
max_connections— 1С обычно требует 100–200 подключений. Устанавливайте с запасом.
max_connections = 200escape_string_warning и standard_conforming_strings — для совместимости с текстами запросов 1С.
escape_string_warning = off
standard_conforming_strings = offЭти директивы упомянуты в официальной документации по настройке PostgreSQL для 1С.
Также полезно увеличить max_locks_per_transaction, если 1С жалуется на нехватку блокировок:
max_locks_per_transaction = 256Шаг 6. Обновление статистики и автовакуум
autovacuum — для 1С критически важен, чтобы не допускать разрастания таблиц. Убедитесь, что он включён, и настройте более агрессивный режим.
autovacuum = on autovacuum_max_workers = 4 autovacuum_naptime = 30s autovacuum_vacuum_scale_factor = 0.05 autovacuum_analyze_scale_factor = 0.02
Подробнее: Autovacuum Tuning.
Шаг 7. Применение конфигурации и перезапуск
После изменения файла сохраните его и перезапустите сервер PostgreSQL:
bash
sudo systemctl restart postgresqlПроверьте, что сервер запустился с новыми параметрами:
bash
sudo -u postgres psql -c "SHOW shared_buffers;"Шаг 8. Тестирование производительности
Для быстрой проверки используйте встроенный инструмент pgbench. Инициализируйте тестовую базу и запустите нагрузочный тест:
bash
sudo -u postgres pgbench -i -s 10 testdb
sudo -u postgres pgbench -c 20 -T 60 testdbСравните транзакции в секунду (TPS) до и после настройки. Значительный прирост указывает на корректность изменений.
Устранение распространённых проблем
| Симптом | Вероятная причина | Решение |
|---|---|---|
После увеличения shared_buffers производительность упала | Слишком большая доля ОЗУ отдана PostgreSQL, страничный кеш ОС уменьшился, что замедлило чтение файлов | Снизьте shared_buffers до 20-25% ОЗУ и увеличьте effective_cache_size. |
Запросы 1С выполняются с высоким IO:Timing | Планировщик выбирает Seq Scan вместо Index Scan из-за высокого random_page_cost | Установите random_page_cost = 1.1 для SSD. |
| Ошибка «too many clients» в 1С | Превышено max_connections | Увеличьте max_connections с запасом (200-300) и перезапустите PostgreSQL. |
| База «раздувается», несмотря на VACUUM | Неправильно настроен autovacuum, не успевает обрабатывать | Уменьшите autovacuum_vacuum_scale_factor до 0.01-0.05, увеличьте количество workers до 4-6. |
После настройки synchronous_commit=off 1С теряет данные при сбоях | Ожидаемое поведение: жертва надёжности ради скорости | Для финансовых систем верните on и оптимизируйте дисковую подсистему. |
Итог
PostgreSQL настройка производительности это итеративный процесс, требующий анализа реальной нагрузки. Приведённые параметры создают надежный фундамент для сервера 1С и других высоконагруженных систем, позволяя полностью утилизировать доступную память и возможности современных SSD. После изменения конфигурации обязательно наблюдайте за поведением базы с помощью pg_stat_statements, pgBadger или встроенного мониторинга 1С и корректируйте work_mem или random_page_cost под характер запросов. Следование рекомендациям сообщества и официальной документации Postgres Professional гарантирует стабильную и быструю работу даже при одновременной работе сотен пользователей.
