← На главную

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

Анализ поведения платформы и замер производительности

Для выяснения причин замедления первым делом выполним замер производительности во встроенном конфигураторе. Запустим сеанс тонкого клиента в режиме отладки, включим замер и проведем проблемный документ. Результаты замера показывают критическую точку:

Строка кода, потребляющая более 70% всего времени операции проведения:

Оповестить("ИзменениеВыписки");

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

В конфигурации «Бухгалтерия предприятия» на системное событие "ИзменениеВыписки" подписан журнал документов Банковские выписки. Если форма этого журнала открыта у пользователя в соседней вкладке, при проведении платежки она немедленно инициирует серверный контекстный вызов для решения двух задач:

1. Обновление динамического списка документов по расчетному счету.
2. Полный пересчет дневных остатков и оборотов (остаток на начало дня, приход, расход, остаток на конец дня) с прямым обращением к регистру бухгалтерии.

Именно этот неявный серверный вызов при открытом журнале блокирует интерфейс клиента на время проведения каждого отдельного документа.

Влияние пользовательских настроек на деградацию скорости

Рассмотрим подробнее, почему новый пользователь базы работает быстро, а через день начинает испытывать сильные тормоза. Дело заключается в накоплении индивидуальных пользовательских настроек отображения динамического списка в форме журнала выписок:

1. Сортировка по неиндексированным реквизитам. Достаточно бухгалтеру один раз кликнуть по шапке колонки «Контрагент», «Назначение платежа» или «Статья ДДС», как платформа добавляет в запрос динамического списка конструкцию ORDER BY по этому полю. Если индекс по данному полю отсутствует, СУБД PostgreSQL выполняет полное сканирование таблицы и ресурсоемкую сортировку на диске.
2. Сброс фильтров по расчетному счету и организации. Если в журнале выписок выбран режим отображения по всем банковским счетам сразу, механизм пересчета остатков вынужден рассчитывать итоги по всей базе данных вместо одного конкретного счета.
3. Широкий интервал дат или режим «За все время». Расширение периода отображения вынуждает платформу и СУБД считывать огромные массивы данных при каждом оповещении об изменении выписки.
4. Сложное условное оформление и группировки. Пользовательские группировки кардинально усложняют генерируемый SQL-запрос, лишая динамический список возможности выполнять легкую порционную выборку данных.
5. Активная строка поиска. Сохраненный в поле поиска строковый фрагмент отключает эффективное использование индексов в PostgreSQL.

Способ 1. Быстрое устранение через точечную очистку настроек

Чтобы не пересоздавать учетные записи пользователей каждый день, выполним регламентный сброс только проблемных настроек интерфейса. Проанализируем порядок действий администратора:

1. Перейдем в раздел Администрирование -> Настройки пользователей и прав.
2. Откроем пункт Персональные настройки пользователей -> Очистка настроек.
3. Выберем проблемного пользователя информационной базы.
4. В дереве настроек найдем журнал документов Банковские выписки и очистим настройки внешнего вида и динамического списка, не затрагивая прочие персональные параметры пользователя.

После перезапуска сеанса пользователя форма выписок вернется к заводским настройкам, а скорость проведения документов восстановится до штатных значений.

Способ 2. Организационное разделение работы

Разберем простое правило работы с документами, полностью исключающее проявление данной проблемы: при массовом проведении или заведении платежных поручений журнал «Банковские выписки» должен быть закрыт.

Если вкладка журнала выписок закрыта, вызов метода Оповестить("ИзменениеВыписки") выполняется за доли миллисекунды, так как в клиенте отсутствует активный получатель оповещения, и тяжелый контекстный серверный вызов не запускается вовсе.

Способ 3. Тонкая настройка PostgreSQL под рабочие нагрузки 1С

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

1. Параметр work_mem. Дефолтное значение (часто 4MB) приводит к тому, что сортировка динамических списков при наличии пользовательских отборов не помещается в RAM и сбрасывается во временные файлы на диске. Рекомендуется увеличить значение до 32MB или 64MB.
2. Параметр random_page_cost. При использовании твердотельных накопителей (SSD/NVMe) обязательно уменьшим параметр с 4.0 до 1.1 - 1.3. Это позволит планировщику запросов PostgreSQL отдавать предпочтение индексным сканированиям вместо тяжелых Seq Scan.
3. Актуализация статистики базы данных. Убедимся, что процесс autovacuum включен. Для таблиц регистра бухгалтерии и банковских документов выполним ручное обновление статистики командой: VACUUM ANALYZE;

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