Как увеличить производительность PostgreSQL для 1С

PostgreSQL — самая распространённая бесплатная СУБД для работы 1С:Предприятие, но «из коробки» она настроена на минимальное потребление ресурсов, а не на скорость. Параметры по умолчанию рассчитаны на слабый сервер с 1–2 ГБ оперативной памяти, поэтому без настройки база 1С на PostgreSQL почти всегда работает медленнее своих возможностей. Правильная конфигурация памяти, фоновых процессов и регулярное обслуживание способны ускорить типовые операции в разы без замены железа.

Проблемы производительности в связке 1С + PostgreSQL обычно сводятся к нескольким причинам: недостаточный объём памяти под кэш, неоптимальные настройки планировщика запросов, раздувание таблиц из-за неагрессивного autovacuum и «тяжёлые» запросы, которые генерирует конфигурация. Важно понимать, что 1С формирует SQL-запросы автоматически, и влиять на них администратор может только косвенно — через настройки СУБД, индексы и регламентные операции.

Перед любыми изменениями снимите полную резервную копию базы штатными средствами (pg_dump или выгрузка через конфигуратор) и убедитесь, что копия восстанавливается. Настройки применяйте поэтапно, фиксируя исходные значения, чтобы при ухудшении можно было быстро откатиться.

Диагностика: что именно тормозит

Прежде чем менять параметры, определите источник проблемы. Медленная работа 1С может быть вызвана сетью, дисковой подсистемой, нехваткой ОЗУ, блокировками или конкретными запросами. Начните с простых наблюдений: загрузка CPU и диска на сервере СУБД в момент «тормозов», объём свободной памяти, скорость отклика диска.

Подключите расширение pg_stat_statements — оно собирает статистику по всем выполняемым запросам: сколько раз вызывался запрос, суммарное и среднее время. Это главный инструмент поиска «тяжёлых» запросов в 1С.

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
SELECT round(total_exec_time::numeric, 2) AS total_ms, calls, round(mean_exec_time::numeric, 2) AS avg_ms, query
FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 20;

Дополнительно проверьте размер базы и самых больших таблиц — в 1С это обычно регистры накопления, сведений и таблицы итогов. Раздутая таблица с устаревшими версиями строк (dead tuples) — частая причина деградации скорости даже при хорошем железе.

Настройка памяти: shared_buffers, work_mem, effective_cache_size

Ключевой параметр — shared_buffers: объём памяти, который PostgreSQL выделяет под собственный кэш данных. Для выделенного сервера 1С обычно рекомендуют 25–30% от общего объёма ОЗУ. На сервере с 32 ГБ это 8–10 ГБ. Сильно больше выделять не стоит: PostgreSQL активно использует и файловый кэш операционной системы.

Параметр effective_cache_size не выделяет память, а подсказывает планировщику, сколько данных примерно доступно в кэше ОС. Ставьте его на уровне 50–70% от объёма ОЗУ — это влияет на выбор планов запросов в пользу индексного доступа вместо полного сканирования.

Параметр work_mem определяет память на одну операцию сортировки или хэширования. Для 1С, где запросы часто содержат соединения множества таблиц, разумное значение — 64–256 МБ. Учтите: один сложный запрос может использовать work_mem несколько раз, а одновременных соединений много, поэтому не завышайте значение — иначе сервер уйдёт в подкачку.

# postgresql.conf для сервера с 32 ГБ ОЗУ
shared_buffers = 8GB
effective_cache_size = 20GB
work_mem = 128MB
maintenance_work_mem = 2GB
max_connections = 200

После изменения shared_buffers требуется перезапуск службы PostgreSQL, поэтому планируйте работы на нерабочее время. Изменение work_mem и effective_cache_size применяется перезагрузкой конфигурации без остановки сервера.

Autovacuum и борьба с раздуванием таблиц

PostgreSQL не удаляет старые версии строк сразу — их убирает фоновый процесс autovacuum. В базах 1С с интенсивной записью (проведение документов, обмены данными) стандартные настройки autovacuum слишком «ленивые»: таблицы раздуваются, запросы начинают читать в разы больше страниц, чем нужно, и производительность падает постепенно, незаметно для пользователей.

Для нагруженных баз 1С рекомендуется сделать autovacuum агрессивнее: увеличить количество воркеров, снизить пороги срабатывания и уменьшить задержки между проходами. Одновременно поднимите maintenance_work_mem — это ускорит VACUUM и создание индексов.

autovacuum = on
autovacuum_max_workers = 4
autovacuum_naptime = 20s
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02
autovacuum_vacuum_cost_delay = 10ms

Контролируйте результат через представление pg_stat_user_tables: смотрите колонки n_dead_tup (число «мёртвых» строк) и last_autovacuum. Если dead tuples исчисляются миллионами, а autovacuum давно не запускался — таблице требуется вмешательство. Для критичных таблиц, уже сильно раздутых, однократно выполните VACUUM FULL в нерабочее время (учтите: он блокирует таблицу на всё время работы).

Регламентные операции: обновление статистики и реиндексация

Планировщик PostgreSQL выбирает план запроса на основе статистики о распределении данных. Если статистика устарела (а в 1С данные меняются постоянно), оптимизатор начинает выбирать неоптимальные планы: полное сканирование вместо индекса, неверный порядок соединений. Характерный симптом — запрос, который «вчера работал быстро, а сегодня висит».

Настройте регулярное выполнение ANALYZE по всей базе — обычно достаточно раза в день в нерабочее время, а для очень активных баз — чаще. Автоанализ, включённый вместе с autovacuum, часто справляется сам, но ручной запуск после массовых загрузок данных (обмены, загрузка прайсов, свёртка) обязателен.

Реиндексация нужна реже: индексы в PostgreSQL со временем деградируют из-за удалений и обновлений. Для большинства баз 1С достаточно REINDEX раз в неделю или раз в месяц в окно обслуживания. Используйте REINDEX CONCURRENTLY, если нужно избежать полной блокировки (доступно не для всех объектов и работает медленнее).

1. 1
   Ежедневно в нерабочее время: ANALYZE по всей базе
2. 2
   Еженедельно: REINDEX базы или наиболее нагруженных таблиц
3. 3
   Еженедельно: проверка pg_stat_user_tables на раздувание таблиц
4. 4
   Ежемесячно: анализ топа запросов pg_stat_statements
5. 5
   После массовых загрузок и обменов: внеочередной ANALYZE
6. 6
   Перед каждым регламентом: контроль наличия свежей резервной копии

Оптимизация со стороны 1С и конфигурации

Часть «тормозов» лежит не в СУБД, а в том, как конфигурация работает с данными. Проверьте настройки управляемых блокировок: для PostgreSQL в большинстве случаев рекомендуется режим управляемых блокировок вместо автоматических — он снижает число взаимоблокировок и ложных конфликтов при параллельной работе пользователей.

Обратите внимание на итоги регистров: убедитесь, что хранение итогов включено и актуально, а устаревшие периоды закрыты. Отчёты по регистрам с отключенными или «разваленными» итогами выполняются полным сканированием и грузят сервер. Также проверьте журналы регистрации — при детальном уровне логирования они растут быстро и замедляют обслуживание.

Для нестандартных доработок используйте технологический журнал 1С совместно с данными pg_stat_statements: так можно связать конкретную операцию в конфигурации с SQL-запросом и понять, где проблема — в коде, индексе или плане. Изменения запросов в коде конфигурации (уменьшение выборок, отказ от запросов в цикле) часто дают больший эффект, чем любая настройка СУБД.

Железо и размещение данных

Никакая настройка не компенсирует медленные диски. Для баз 1С критична задержка при случайном чтении и скорость записи журнала WAL, поэтому SSD (лучше NVMe) — фактически обязательное требование для рабочих баз среднего и крупного размера. Размещение каталога pg_wal на отдельном быстром диске снижает конкуренцию за дисковые ресурсы при интенсивной записи.

По процессору PostgreSQL выигрывает от высокой тактовой частоты сильнее, чем от большого числа медленных ядер: один запрос выполняется в основном одним потоком. Для сервера 1С это значит, что 8 быстрых ядер предпочтительнее 16 медленных. Память берите с запасом: ОС, сервер 1С (rphost) и PostgreSQL конкурируют за ОЗУ, если размещены на одной машине.

Как проверить, что настройки сработали

Измеряйте эффект до и после изменений. Зафиксируйте время выполнения характерных операций: проведение крупного документа, формирование ключевого отчёта, закрытие месяца. После применения настроек повторите замеры в сопоставимых условиях — только так можно объективно оценить результат.

В самой СУБД контролируйте долю попаданий в кэш (hit ratio) по pg_stat_database: для «прогретой» рабочей базы нормальным считается значение около 99% и выше. Низкий показатель означает, что данные не помещаются в кэш и PostgreSQL постоянно читает с диска — стоит пересмотреть shared_buffers или объём ОЗУ.

FAQ