Настройка PostgreSQL для 1С при медленном закрытии месяца

В кейсе PGLens одна операция 1С обращалась к таблице 20 000 раз подряд. Каждый запрос занимал 190 мс. В сумме ожидание СУБД достигло 3 800 секунд — 63 минут 20 секунд.

После настройки PostgreSQL один запрос занимал уже 1,9 мс, а весь расчёт — 38 секунд. Но причина осталась в прикладной логике 1С. Серверные параметры ускорили неудачный алгоритм, а не исправили его.

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

Снимайте показатели во время медленной операции

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

Во время того же запуска соберите данные с трёх сторон:

• rac — загрузка rphost, память рабочих процессов, сеансы и соединения;
• технологический журнал 1С — контекст операции и длительные вызовы;
• pg_stat_statements — запросы, на которые PostgreSQL потратил больше всего времени.

Материал Integration Software даёт два порога для первичной проверки. Первый — CPU выше 80% в течение 15 минут. Второй — дисковая задержка выше 20 мс. Оба порога указывают, какой слой проверять дальше, но сами по себе причину не доказывают.

Таблица нужна не для настройки по симптомам. Она помогает выбрать следующую проверку и не менять PostgreSQL наугад.

Если медленно работает не одна операция, пройдите проверку медленной 1С по уровням системы. Она отделит задержку сеанса от проблем базы, сети, СУБД и дисков.

Отделите тяжёлый запрос от частого

Один медленный запрос и 20 000 быстрых требуют разных действий. В первом случае администратор изучает план PostgreSQL. Во втором разработчик меняет прикладную логику 1С.

Отсортируйте pg_stat_statements по суммарному времени. Рядом смотрите число вызовов, среднее и общее время. Если взять только один показатель, легко выбрать не тот запрос.

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

Для временного поиска долгих запросов руководство Server Admin предлагает такой параметр:

log_min_duration_statement = 3000

PostgreSQL запишет запросы, которые выполняются дольше трёх секунд. Лог займёт место и добавит ввод-вывод. Поэтому включайте параметр только на время диагностики, следите за свободным местом и настройте ротацию.

Запрос, который один раз работает несколько секунд, проверьте через EXPLAIN. Начните со статистики таблиц, условий отбора и индексов. Наличие индекса ещё не означает, что планировщик его выберет.

У частого короткого запроса другая картина. PostgreSQL быстро выполняет каждый вызов, но 1С повторяет его снова и снова. Зафиксируйте операцию, текст запроса, число обращений и суммарное время. Разработчик получит задачу, результат которой можно проверить.

Кейс PGLens сочетает оба сценария. Настройка СУБД сократила один вызов со 190 до 1,9 мс. Но 20 000 последовательных обращений никуда не делись: их создавала бизнес-логика 1С.

Рассчитайте память от доступного объёма

Рекомендации 1С от 19 июня 2025 года относятся к PostgreSQL 9.6 и новее. Для shared_buffers они задают четверть RAM. На выделенном сервере со 128 ГБ расчёт выглядит так:

shared_buffers = 128 ГБ / 4 = 32 ГБ
effective_cache_size = 128 ГБ − 32 ГБ = 96 ГБ

effective_cache_size не резервирует 96 ГБ памяти. Он сообщает планировщику, сколько данных может находиться в кэше PostgreSQL и ОС.

Для work_mem возьмём формулу из руководства Andko:

work_mem =
(RAM − shared_buffers) / (max_connections × 4)

Множитель четыре — это допущение. Одно соединение может одновременно держать несколько операций сортировки или хеширования.

При 128 ГБ RAM и max_connections = 200 получаем:

work_mem = (128 − 32) / (200 × 4)
work_mem = 0,12 ГБ ≈ 123 МБ

123 МБ — стартовый потолок, а не постоянный расход каждого соединения. PostgreSQL выделяет work_mem отдельным операциям. Один сложный запрос может запросить несколько таких областей.

Рекомендации 1С предлагают считать maintenance_work_mem как четыре work_mem. В нашем примере выходит около 492 МБ:

maintenance_work_mem = 123 МБ × 4 ≈ 492 МБ

Число попадает в диапазон 1С от 256 МБ до 4 ГБ. Этот параметр влияет на VACUUM, создание индексов и другие служебные операции.

Если PostgreSQL делит машину с сервером 1С, считать от всей RAM нельзя. Руководство Andko предлагает отдать СУБД половину физической памяти. На машине со 128 ГБ бюджет PostgreSQL составит 64 ГБ.

Стартовые параметры тогда изменятся:

shared_buffers = 64 / 4 = 16 ГБ
effective_cache_size = 64 − 16 = 48 ГБ
work_mem = (64 − 16) / (200 × 4) ≈ 61 МБ
maintenance_work_mem ≈ 244 МБ

Расчётный maintenance_work_mem немного не дотягивает до нижней границы рекомендации 1С. Возьмите для старта 256 МБ и проверьте расход памяти во время обслуживания.

При другом числе соединений пересчитайте формулу. Если поднять max_connections с 200 до 400, расчётный work_mem уменьшится вдвое. Значение 123 МБ нельзя переносить на сервер с другим лимитом подключений.

После расчёта проверьте резерв больших страниц в ОС. Порядок действий описан в инструкции по настройке Huge Pages под объём памяти PostgreSQL.

Настройте WAL и обслуживание без потери данных

Параметры записи и контрольных точек влияют не только на время закрытия. Ошибка в них увеличит объём данных, потерянных при сбое.

Начинайте с параметров, связанных с найденной задержкой. После изменения смотрите не только длительность операции, но и WAL, контрольные точки, планы и диск.

fsync на рабочей базе не отключают. Рекомендации 1С задают on. Руководство Andko допускает off только в тестовой среде.

По synchronous_commit рекомендации расходятся. Материал 1С предлагает off. Руководство Andko считает on безопасным режимом, а remote_write — компромиссом.

Переход на off требует заранее согласовать допустимую потерю последних транзакций. Нет такого решения — оставьте on. Несколько выигранных секунд не стоят неизвестного объёма потерь при аварии.

Для сервера с 16 ядрами рекомендации 1С дают такой расчёт:

autovacuum_max_workers = CPU / 4
autovacuum_max_workers = 16 / 4 = 4

Рекомендация ограничивает параметр четырьмя процессами. На 32 ядрах формула даст восемь, но стартовое значение останется равным четырём.

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

Проверьте рабочие процессы 1С

Даже при корректных параметрах PostgreSQL закрытие может задерживать rphost. Такое случается, если процесс обслуживает несколько тяжёлых баз или упирается в лимит памяти.

Для контура на 50–100 пользователей материал Integration Software предлагает следующие отправные значения:

Эти значения подходят только как начало проверки для указанной нагрузки. Оставляйте их после контрольного запуска на своей базе.

Не меняйте сразу число потоков, память и количество баз на процесс. Новое время вы увидите, но причину улучшения не найдёте. Меняйте один связанный набор параметров за запуск.

Если 1С и PostgreSQL постоянно делят CPU и RAM, у общей машины быстро заканчивается запас для настройки. Тогда стоит разнести сервер приложений и СУБД по двум узлам.

Стартовая конфигурация для 128 ГБ и 200 подключений

Для выделенного сервера PostgreSQL со 128 ГБ RAM стартовый набор выглядит так:

shared_buffers = 32GB
effective_cache_size = 96GB
work_mem = 123MB
maintenance_work_mem = 492MB

fsync = on
checkpoint_completion_target = 0.9
min_wal_size = 1GB
max_wal_size = 2GB

autovacuum = on
autovacuum_naptime = 20s
autovacuum_max_workers = 4

Расчёт предполагает 200 подключений, 16 ядер и отдельный сервер СУБД. Для SSD начните с random_page_cost в диапазоне 1.1–1.3. Итоговое значение выбирайте по планам и фактическому времени запросов.

Перед следующим закрытием месяца пройдите один цикл:

1. Запишите длительность контрольной операции.
2. Снимите данные из rac, технологического журнала и pg_stat_statements.
3. Найдите слой с наибольшим суммарным временем.
4. Измените один связанный набор параметров.
5. Повторите ту же операцию и сравните время.

Время не сократилось — верните изменение и переходите к следующему слою. Покупать процессор стоит после подтверждённой нехватки CPU. Настраивать PostgreSQL — после подтверждённой задержки в СУБД.