При работе с крупными базами 1С:Бухгалтерия предприятия 3.0 на операционной системе Linux или Windows в связке с PostgreSQL администраторы и разработчики часто сталкиваются с деградацией производительности в списке банковских выписок. Основной симптом: при перелистывании строк журнала документов система «задумывается» на несколько секунд, а процессор сервера загружается тяжелыми SQL-запросами. Рассмотрим подробнее, почему это происходит и как решить проблему системно.
Для начала проанализируем ситуацию. Когда пользователь листает список выписок, система динамически рассчитывает итоги по расчетному счету на дату документа. В типовой конфигурации за это отвечает функция ПолучитьИтоги. Если включить Технологический журнал (ТЖ), мы увидим, что платформа генерирует сложный SQL-запрос к виртуальной таблице РегистрБухгалтерии.Хозрасчетный.ОстаткиИОбороты.
Проблема в том, что для PostgreSQL такие запросы часто становятся «непрозрачными». Вложенные подзапросы и множественные соединения (JOIN) таблиц остатков и движений приводят к тому, что планировщик СУБД выбирает неоптимальный план выполнения. Вместо быстрого поиска по индексам (Index Scan) может начаться полное сканирование таблиц (Seq Scan), что и вызывает задержки.
Посмотрим на пример типового запроса, который вызывает тормоза. Обратите внимание на использование конструкции ВЫРАЗИТЬ в параметрах виртуальной таблицы:
ПостроительЗапроса.Текст =
"ВЫБРАТЬ
| ...
|ИЗ
| РегистрБухгалтерии.Хозрасчетный.ОстаткиИОбороты(
| &ДатаИтоговНачалоДня,
| &ДатаИтоговКонецДня,
| ,
| ДвиженияИГраницыПериода,
| Счет В (&СчетаССубконтоБанковскиеСчета),
| &ВидСубконтоБанковскиеСчета,
| Организация В (&Организации)
| {(ВЫРАЗИТЬ(Субконто1 КАК Справочник.БанковскиеСчета)) КАК БанковскийСчетИтогов}) КАК БИ";
Выясним причину замедления: использование ВЫРАЗИТЬ в условиях ГДЕ или параметрах виртуальных таблиц в PostgreSQL часто мешает планировщику использовать индексы по полям составного типа (каким является Субконто). Поскольку конфигурация «на замке», для исправления ситуации воспользуемся механизмом расширений.
Разберем по шагам, что можно сделать в расширении:
ПолучитьИтоги в модуле формы или менеджера (в зависимости от версии БП).ВЫРАЗИТЬ, если отбор по ВидСубконто уже гарантирует нужный тип данных.ОстаткиИОбороты на два простых запроса к таблицам Остатки и Обороты с последующим объединением во временной таблице.Прежде чем глубоко копаться в настройках СУБД, выполним стандартные процедуры обслуживания базы данных 1С. Часто причиной тормозов являются «разваленные» итоги или некорректные записи в таблицах остатков.
Проанализируем состояние итогов: перейдем в Все функции — Стандартные — Управление итогами. Убедимся, что итоги рассчитаны по текущий месяц. Если период расчета итогов сильно отстает от текущей даты, 1С будет вынуждена каждый раз вычислять остатки, складывая все движения от последней рассчитанной точки, что крайне медленно.
Выполним Тестирование и исправление (ТиИ) со следующими настройками:
_AccRgAT (таблицы итогов).Если после ТиИ проблема сохраняется, перейдем к администрированию СУБД. PostgreSQL требует регулярного обновления статистики, чтобы планировщик понимал распределение данных в таблицах.
Рассмотрим разницу между основными командами обслуживания:
Хозрасчетный, так как он постоянно растет.Для выполнения обслуживания через консоль используем утилиту vacuumdb:
# Обновление статистики для всех баз
vacuumdb --all --analyze-only
# Полная очистка конкретной базы
vacuumdb --full --analyze --dbname=your_database_name
Важный момент: Если ваша база работает медленно именно на операциях чтения (как в случае с итогами), обязательно проверьте настройки планировщика в postgresql.conf. Для баз 1С на SSD дисках параметры random_page_cost рекомендуется устанавливать в значение 1.1 (вместо стандартных 4.0), чтобы СУБД охотнее использовала индексы.
Иногда причиной «зависания» запроса является наличие в базе записей с некорректными датами (например, документы из 3999 года или 0001 года). PostgreSQL может некорректно обрабатывать такие диапазоны в индексах виртуальных таблиц. Попробуем выполнить простой запрос, чтобы найти такие записи:
ВЫБРАТЬ
Хозрасчетный.Регистратор,
Хозрасчетный.Период
ИЗ
РегистрБухгалтерии.Хозрасчетный КАК Хозрасчетный
ГДЕ
Хозрасчетный.Период > ДАТАВРЕМЯ(2050, 1, 1)
Если такие записи обнаружены, их необходимо исправить или удалить, после чего повторно выполнить пересчет итогов.
Мы проанализировали ситуацию с долгим расчетом итогов по регистру Хозрасчетный и выяснили, что решение всегда носит комплексный характер. Совместная работа программиста 1С и системного администратора должна включать:
vacuumdb --analyze каждую ночь.Помните, что PostgreSQL — это мощный инструмент, который требует чуть больше внимания к статистике и настройкам планировщика, чем MS SQL Server, но при правильном подходе он обеспечивает сопоставимую производительность для большинства задач 1С:Бухгалтерии.