Как ускорить работу 1С на PostgreSQL

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

Ускорение достигается комплексом мер: настройкой памяти PostgreSQL, корректной работой autovacuum, контролем индексов, обновлением статистики и оптимизацией самих запросов 1С. Отдельно стоит проверить дисковую подсистему и сетевое взаимодействие между сервером 1С и сервером СУБД, если они разнесены на разные машины.

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

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

Первый шаг — определить, где теряется время: на стороне СУБД, сервера 1С или клиента. Включите технологический журнал 1С с событием DBPOSTGRS и смотрите длительность запросов. Если запросы выполняются долго (сотни миллисекунд и больше на простых операциях) — проблема в СУБД. Если запросы быстрые, а операция всё равно идёт медленно — ищите причину в коде конфигурации, блокировках или на сервере приложений.

Для анализа на стороне PostgreSQL включите логирование медленных запросов через параметр log_min_duration_statement, например на значение 500 мс. После нескольких часов работы в логе накопятся конкретные запросы, которые можно разобрать через EXPLAIN ANALYZE. Также полезно посмотреть представление pg_stat_activity — оно покажет зависшие сессии и блокировки.

Настройка памяти PostgreSQL

Главный параметр — shared_buffers: объём разделяемой памяти под кэш данных. Для выделенного сервера 1С обычно рекомендуют начинать с 25% от объёма оперативной памяти и наблюдать за поведением. Слишком большое значение не всегда лучше: двойное кэширование (PostgreSQL и ОС) может не дать выигрыша, а на части систем — ухудшить работу.

Параметр effective_cache_size не выделяет память, а подсказывает планировщику, сколько данных реально может находиться в кэше ОС. Его разумно устанавливать на уровне 50–75% от общего объёма RAM. work_mem определяет память на операции сортировки и хеширования в рамках одного запроса: для 1С с её тяжёлыми отчётами значение по умолчанию (4 МБ) обычно мало, но сильно завышать опасно — память выделяется на каждую операцию каждого соединения.

Дополнительно обратите внимание на maintenance_work_mem — память для операций VACUUM, CREATE INDEX, REINDEX. Увеличение до нескольких сотен мегабайт заметно ускоряет обслуживание больших баз. После изменения параметров памяти требуется перезапуск службы PostgreSQL.

# Пример фрагмента postgresql.conf для сервера с 32 ГБ RAM
shared_buffers = 8GB
effective_cache_size = 20GB
work_mem = 64MB
maintenance_work_mem = 1GB
max_connections = 300
random_page_cost = 1.1
effective_io_concurrency = 200

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

PostgreSQL использует механизм MVCC: обновление строки создаёт новую версию, а старая остаётся в таблице до очистки. Для 1С с её интенсивной записью в регистры это критично — без регулярного autovacuum таблицы раздуваются, и запросы начинают читать всё больше «мёртвых» строк. Характерный симптом: база растёт быстрее, чем добавляются данные, а запросы постепенно деградируют.

Настройки autovacuum по умолчанию слишком ленивы для 1С. Уменьшите autovacuum_vacuum_scale_factor (например, до 0.05–0.1) и autovacuum_analyze_scale_factor, увеличьте autovacuum_max_workers. Для самых активных таблиц (регистры накопления, сведений) можно задать индивидуальные параметры через ALTER TABLE ... SET (autovacuum_vacuum_scale_factor = ...).

Актуальная статистика (ANALYZE) нужна планировщику для выбора правильного плана запроса. Если после обновления статистики запрос резко ускорился — значит, проблема была именно в ней. Полезно периодически проверять pg_stat_user_tables: колонки n_dead_tup и last_autovacuum покажут, справляется ли автоматика.

Индексы и планы запросов

1С создаёт индексы по структуре метаданных, но на больших объёмах их может не хватать для специфических выборок. Анализ EXPLAIN ANALYZE покажет, используется ли индекс или выполняется последовательное сканирование (Seq Scan) большой таблицы. Seq Scan на таблице итогов с миллионами строк — почти всегда признак отсутствующего индекса или неактуальной статистики.

Обратная сторона — избыточные индексы. Каждый индекс замедляет вставку и обновление, а 1С активно пишет в регистры. Представление pg_stat_user_indexes помогает найти индексы, которые не используются (idx_scan близко к нулю). Удалять их следует осторожно: часть индексов создаёт платформа автоматически, и они могут понадобиться после обновления конфигурации.

Если запрос выбирает неоптимальный план при наличии индекса, чаще всего помогает ANALYZE по таблице. Реже — корректировка default_statistics_target для конкретных колонок. Не применяйте подсказки планировщику и не отключайте типы сканирования (enable_seqscan = off) как постоянное решение: это маскирует проблему и ломает другие запросы.

Диски, WAL и сеть

Для 1С критична скорость случайной записи: регистры обновляются постоянно. Размещение базы на SSD вместо HDD даёт эффект, сопоставимый со всей остальной настройкой вместе взятой. Если сервер на SSD, адаптируйте параметры: random_page_cost ближе к 1.1–1.5 (вместо 4 по умолчанию) и effective_io_concurrency 200–300.

Каталог pg_wal (журнал предзаписи) желательно держать на быстром диске, при высокой нагрузке на запись — на отдельном. Параметры max_wal_size и checkpoint_completion_target влияют на равномерность нагрузки: увеличение max_wal_size снижает частоту контрольных точек и сглаживает всплески записи, но удлиняет восстановление после сбоя.

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

Сторона 1С: код, регламентные задания и индексация

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

Регламентные и фоновые задания могут конкурировать за ресурсы с работой пользователей. Перенесите тяжёлые операции (расчёт итогов, обмены, загрузка данных) на нерабочие часы. Проверьте, не запущено ли одновременно несколько копий одного задания — это типичная причина взаимных блокировок.

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

1. 1
   Сделайте резервную копию и замерьте время типовых операций: проведение документа, ключевой отчёт, закрытие периода
2. 2
   Включите логирование медленных запросов (log_min_duration_statement) и соберите статистику за рабочий день
3. 3
   Настройте память: shared_buffers, effective_cache_size, work_mem, maintenance_work_mem — с перезапуском службы
4. 4
   Ускорьте autovacuum и выполните ANALYZE по базе; проверьте n_dead_tup в pg_stat_user_tables
5. 5
   Разберите топ медленных запросов через EXPLAIN ANALYZE, добавьте недостающие индексы, обновите статистику
6. 6
   Перенесите тяжёлые регламентные задания на нерабочее время и устраните конкуренцию за блокировки
7. 7
   Повторите исходные замеры и сравните результаты; неудачные изменения откатите по одному

Проверка результата и границы самостоятельной работы

Критерий успеха — не «стало субъективно быстрее», а цифры: время проведения документа, формирования отчёта и выполнения регламентных операций до и после настройки. Дополнительно наблюдайте за системой несколько дней: настройка, улучшившая работу в моменте, может дать деградацию под реальной нагрузкой (например, из-за нехватки памяти в пике).

Самостоятельно безопасно выполнять: настройку параметров памяти в разумных пределах, включение логирования, ANALYZE, перенос регламентных заданий, анализ планов запросов. К специалистам стоит привлекать: VACUUM FULL и REINDEX на больших таблицах, изменение структуры индексов, настройку репликации и кластерных решений, а также любые действия, если нет проверенной резервной копии.

Частые вопросы