При работе с крупными информационными базами 1С на связке с PostgreSQL пользователи часто сталкиваются с неприятной ситуацией: основной отчет (например, Анализ счета) формируется быстро, но при попытке расшифровать конкретную цифру (дрилл-даун) система «замирает», показывая анимированную кошку на полчаса. При этом, если сохранить этот же отчет в «Избранное» и запустить напрямую, он формируется за считанные секунды. В этой статье мы подробно разберем, почему так происходит, проанализируем влияние платформы, настроек СУБД и операционной системы Windows Server на производительность отчетов.
Для начала выясним причину такого поведения системы. Когда мы запускаем отчет из «Избранного», 1С формирует запрос «с чистого листа», используя только сохраненные настройки компоновки данных. Однако при клике на расшифровку (дрилл-даун) платформа 1С пытается передать в новый запрос весь контекст родительского отчета. Это включает в себя огромный массив параметров, фильтров и, что самое важное, зачастую переиспользует временные таблицы, созданные в текущем сеансе.
В версиях платформы 8.3.24.х и 8.3.25.х были зафиксированы изменения в механизмах работы с временными таблицами в PostgreSQL. Оптимизатор запросов СУБД иногда не может построить адекватный план для расшифровки, так как статистика по временным таблицам еще не актуальна или план запроса был закэширован для другого набора данных. Это приводит к тому, что вместо использования индексов PostgreSQL начинает выполнять полное сканирование таблиц (Sequential Scan), что мгновенно нагружает дисковую подсистему и вешает сервер 1С.
Первым делом проанализируем ситуацию с версией платформы. Практика показывает, что на версии 8.3.24.1586 наблюдаются серьезные проблемы с высвобождением ресурсов. Обновление до актуальных релизов ветки 8.3.25 (например, 25.1560 и выше) часто снимает критические зависания, хотя время формирования может оставаться в районе 20–40 секунд, что тоже требует дальнейшей оптимизации.
Также стоит проверить, не вмешиваются ли в процесс расшифровки доработки или расширения. Проанализируем общий модуль ОтчетыКлиент или ОтчетыКлиентПереопределяемый. Именно там располагаются процедуры ОбработкаРасшифровки и ОбработкаДополнительнойРасшифровки. Если в конфигурации есть расширения, попробуйте временно отключить их для теста производительности. Если после отключения расширений расшифровка «летает», значит, проблема в неоптимальном коде, который добавляет лишние условия в запрос.
Если обновление платформы не помогло до конца, перейдем к «гигиеническим» процедурам СУБД. В PostgreSQL, в отличие от MS SQL Server, неиспользуемое место внутри таблиц и индексов (bloat) не возвращается операционной системе автоматически. Это «раздувание» базы сильно замедляет сложные запросы расшифровки.
Рассмотрим процесс «шринга» (сжатия) базы через утилиту vacuumdb. Выполним полную очистку. Внимание: эта операция полностью блокирует таблицы, поэтому ее нужно проводить, когда в базе нет пользователей и отключены регламентные задания.
vacuumdb --full --verbose --analyze --dbname=имя_вашей_базы
vacuumdb -j 8 --analyze-only --dbname=имя_вашей_базы
Альтернативный вариант — выгрузка базы в .dt и загрузка обратно. При загрузке 1С пересоздает все индексы и таблицы «с нуля», что фактически заменяет собой VACUUM FULL и REINDEX.
Зачастую стандартных настроек (вроде shared_buffers = RAM/4) недостаточно. Если расшифровка вешает очередь диска, значит, СУБД не хватает памяти для сортировки данных в ОЗУ, и она уходит в «своп» на диск. Посмотрим, какие параметры стоит подправить в postgresql.conf:
force_custom_plan. Это заставит PostgreSQL пересчитывать план запроса при каждом выполнении, игнорируя кэшированные планы, которые могут быть ошибочными для специфических параметров расшифровки.Если ваша система работает на устаревшей ОС Windows Server 2008, возникают дополнительные риски. Проанализируем сетевые задержки и работу с диском. На старых версиях Windows часто возникают проблемы с резолвом имен через IPv6. Если сервер 1С и PostgreSQL стоят на одной машине, убедитесь, что в настройках подключения и в файле pg_hba.conf везде явно указан IP 127.0.0.1 вместо localhost.
Также проверим антивирусную проверку. В исключения должны быть добавлены:
ragent (сервер 1С), так как при формировании тяжелых отчетов платформа создает там временные файлы подкачки.Автор темы упоминал, что система «зависает в регламентных фоновых». В 1С:Бухгалтерии есть ряд тяжелых заданий, таких как Обновление агрегатов или Слияние индекса полнотекстового поиска. Если запуск такого задания совпадает по времени с попыткой пользователя расшифровать сложный отчет, возникает коллизия на уровне дискового ввода-вывода (I/O Wait). Проанализируем расписание заданий в консоли администрирования 1С и разнесем их выполнение на ночное время или периоды минимальной активности пользователей.
Резюмируем: Для исправления зависаний при расшифровке отчетов необходимо действовать комплексно: обновить платформу до 8.3.25, выполнить полное обслуживание базы через VACUUM FULL, увеличить лимиты оперативной памяти для запросов в настройках PostgreSQL и минимизировать влияние фоновых процессов в рабочее время.