В процессе эксплуатации 1С:Предприятие 8.3 в связке с СУБД PostgreSQL пользователи часто сталкиваются со специфической проблемой: формирование стандартных отчетов (например, Оборотно-сальдовой ведомости) занимает считанные секунды, если выбран период «календарный месяц», но превращается в многоминутное ожидание, если указать произвольную дату в середине месяца. Разберем подробно причины этого явления и методы оптимизации производительности системы.
Для понимания причин тормозов проанализируем, как платформа 1С обращается к данным. В системе существуют таблицы итогов, которые хранят рассчитанные значения остатков на начало каждого месяца. Рассмотрим два сценария формирования отчета:
Именно на этапе «досчета» остатков от ближайшей точки хранения итогов возникают основные задержки. Если дисковая подсистема или настройки СУБД не оптимальны, расчет этой разницы может занять в сотни раз больше времени, чем получение готового итога.
Выясним причину, по которой «простые» обороты могут считаться долго. В PostgreSQL при активной работе пользователей (изменении, проведении документов) старые версии строк не удаляются физически, а помечаются как удаленные. Это приводит к явлению Bloat — таблицы и индексы «раздуваются», в них появляется множество «дырок».
Когда 1С формирует ОСВ на 21-е число, PostgreSQL вынужден сканировать таблицу движений регистра бухгалтерии. Если таблица сильно фрагментирована, планировщик запросов может выбрать неоптимальный план (например, полное сканирование таблицы Seq Scan вместо использования индексов), что и приводит к зависаниям на 15–20 минут.
Рассмотрим, почему автору темы помогла выгрузка и последующая загрузка базы в формате .dt. При загрузке данных из .dt платформа 1С пересоздает структуру таблиц в СУБД «с нуля», полностью перестраивает индексы и устраняет любую фрагментацию. Это дает временный эффект идеальной производительности.
Чтобы избежать деградации производительности в будущем, проанализируем критические параметры в конфигурационном файле postgresql.conf. Для баз 1С на платформе Windows Server 2008 R2 и выше рекомендуется проверить следующие настройки:
join_collapse_limit: Рекомендуется установить значение 20 или выше. 1С генерирует сложные запросы с большим количеством соединений. Если лимит низкий, PostgreSQL перестает искать лучший план соединения таблиц.from_collapse_limit: Также рекомендуется значение около 20.autovacuum: Должен быть обязательно включен. Однако стандартных настроек часто недостаточно. Посмотрим на параметры агрессивной очистки:
autovacuum_max_workers = 4
autovacuum_naptime = 20s
autovacuum_vacuum_threshold = 50
autovacuum_analyze_threshold = 50
Эти настройки заставляют СУБД чаще проверять таблицы на наличие «мертвых» строк и актуализировать статистику, что критично для правильной работы планировщика запросов при расчете ОСВ.
Рассмотрим альтернативу долгой процедуре выгрузки/загрузки .dt. Если отчеты начали тормозить, системному администратору следует выполнить регламентные операции непосредственно в консоли СУБД или через pgAdmin. Посмотрим на последовательность действий:
ANALYZE сообщает планировщику актуальное распределение данных в таблицах.VACUUM (без FULL) позволяет пометить свободное место для повторного использования.REINDEX DATABASE.Пример скрипта для регулярного обслуживания через sql-запрос:
VACUUM ANALYZE;
REINDEX DATABASE "имя_вашей_базы";
Важно: Операция REINDEX блокирует таблицы, поэтому ее следует выполнять в периоды отсутствия пользователей в базе.
Проанализируем ситуацию, когда у одного пользователя («А») отчет тормозит, а у другого («Б») в той же сессии — нет. Помимо настроек прав доступа и RLS (ограничение прав на уровне записей), огромную роль играет локальный кэш пользователя.
Платформа 1С хранит настройки отчетов, схемы компоновки данных и временные файлы в папках %LOCALAPPDATA%\1C\1Cv8. При обновлении конфигурации или платформы кэш может стать невалидным, что вызывает ошибки интерпретации запросов. В таких случаях мы рекомендуем:
Local\1C\1Cv8 и Roaming\1C\1Cv8 в профиле пользователя на терминальном сервере.Подводя итог, можно сказать, что проблема «тормозов» ОСВ на произвольные даты в связке 1С + PostgreSQL чаще всего вызвана устаревшей статистикой СУБД или сильной фрагментацией индексов регистра бухгалтерии. Выясним основные шаги для предотвращения проблемы:
VACUUM ANALYZE в ночное время.REINDEX или регламентное тестирование и исправление базы в конфигураторе с пересчетом итогов.temp_tablespaces), так как расчет ОСВ на «нестандартные» даты создает большую нагрузку на temp-файлы.