Почему тормозит 1С:Бухгалтерия 3.0 после проведения документов и как ускорить работу динамических списков на PostgreSQL?

← На главную

При работе в конфигурации «1С:Бухгалтерия предприятия 3.0» на клиент-серверной архитектуре под управлением PostgreSQL пользователи нередко сталкиваются с микрофризами: пролистывание списка банковских выписок или документов реализации происходит с рывками, а после нажатия кнопки «Провести и закрыть» пиктограмма состояния документа в списке обновляется с задержкой в 1–2 секунды даже при минимальном количестве работающих пользователей. Выясним причину такого поведения и разберем по шагам комплекс мер для ускорения работы базы данных.

Проанализируем ситуацию: задержка обновления списка и проведение документа часто связаны не с нехваткой аппаратных мощностей сервера или проблемами локальной сети (ping 10–12 мс без потерь пакетов является допустимым), а с накоплением устаревших версий строк («мертвых кортежей» или dead tuples) и неактуальной статистикой распределения данных в таблицах PostgreSQL.

1. Регламентное обслуживание и настройка Autovacuum в PostgreSQL

Рассмотрим подробнее механизм работы PostgreSQL. При каждом проведении или изменении документа СУБД физически не перезаписывает старую запись, а помечает её как неактуальную и добавляет новую. Если очистка не выполняется вовремя, таблицы и индексы раздуваются (возникает bloat), а оптимизатор запросов строит неоптимальные планы выполнения, выполняя полное сканирование таблицы (Seq Scan) вместо поиска по индексу (Index Scan).

Разовый запуск утилиты vacuumdb позволяет быстро очистить мусор и вернуть производительность, однако для долгосрочной стабильной работы необходимо скорректировать параметры встроенного демона autovacuum в конфигурационном файле postgresql.conf:

Снижение порогов срабатывания очистки и анализа: по умолчанию autovacuum запускается только при изменении 20% строк таблицы, что для больших таблиц 1С слишком редко. Установим параметры:
```
autovacuum_vacuum_scale_factor = 0.02
autovacuum_analyze_scale_factor = 0.02
```
Это заставит СУБД своевременно обновлять статистику и очищать мертвые строки при изменении 2% данных.
Уменьшение интервала сна демона: зададим более частый опрос таблиц: autovacuum_naptime = 15s
Увеличение лимита операций: снизим искусственные ограничения по нагрузке ввода-вывода, чтобы autovacuum не замедлялся: autovacuum_vacuum_cost_limit = 1000

2. Оптимизация параметров PostgreSQL для работы с SSD

Посмотрим на настройки планировщика запросов. По умолчанию параметр random_page_cost в PostgreSQL равен 4.0, что рассчитано на медленные механические жесткие диски (HDD) с большим временем позиционирования головки. При использовании SSD-накопителей стоимость случайного чтения практически равна последовательному.

Откроем файл postgresql.conf и изменим параметр: random_page_cost = 1.1
Перезапустим службу СУБД для применения изменений. Этот параметр позволит планировщику гораздо чаще выбирать эффективное индексное сканирование для запросов динамических списков 1С.
Убедимся, что используется специализированная сборка PostgreSQL с патчами для «1С:Предприятие» (от Postgres Professional или фирмы «1С»), которая оптимизирует работу с временными таблицами, сортировками и управляемыми блокировками.

3. Настройка регламентных заданий и полнотекстового поиска (ППД)

Разберем влияние фоновых процессов платформы. Полнотекстовый поиск данных выполняет постоянную индексацию измененных объектов. Если регламентное задание «Обновление индекса ППД» выполняется каждые 30–60 секунд, оно непрерывно захватывает блокировки, генерирует дисковый трафик и создает конкуренцию за ресурсы с интерактивными транзакциями пользователей.

Перейдем в раздел «Администрирование — Обслуживание — Регламентные операции — Регламентные и фоновые задания».
Найдем задания «Обновление индекса ППД» и «Слияние индексов ППД» и изменим их расписание, настроив запуск во внерабочее время (например, раз в сутки ночью).
Если полнотекстовый поиск по всей базе не используется сотрудниками, его можно полностью отключить в разделе «Администрирование — Общие настройки — Поиск данных», сняв соответствующий флаг и выполнив очистку индекса.
Проанализируем расписание остальных сервисных заданий в БП 3.0 (автоматическая загрузка курсов валют, новостей, классификаторов, фоновые проверки учета) и отключим неиспользуемые.

4. Анализ динамических списков и пользовательских настроек

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

При неактуальной статистике в СУБД соединение динамического списка с регистром сведений выполняется через неоптимальный алгоритм Nested Loop, что приводит к задержке в 1–1,5 секунды при позиционировании на новой строке.
Проверим наличие пользовательских настроек: в форме списка нажмем «Еще — Установить стандартные настройки». Дополнительные отборы по неиндексированным полям табличных частей или тяжелое условное оформление строк часто вызывают рывки при прокрутке.

5. Профилирование с помощью Технологического журнала

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


<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\Logs\1C_SlowQueries" history="24">
        <event>
            <eq property="name" value="DBPOSTGRS"/>
            <gt property="duration" value="1000000"/>
        </event>
        <event>
            <eq property="name" value="TLOCK"/>
        </event>
        <event>
            <eq property="name" value="TTIMEOUT"/>
        </event>
        <property name="all"/>
    </log>
</config>

Этот лог зафиксирует все запросы к PostgreSQL длительностью более 1 секунды (duration > 1000000 мкс), а также покажет возможные конфликты управляемых блокировок (TLOCK, TTIMEOUT) между фоновыми заданиями и интерактивной работой бухгалтера.

6. Очистка кэша тонкого клиента

В качестве дополнительной меры локализации исключим проблемы на стороне рабочего места пользователя. Закроем «1С:Предприятие» и очистим временные файлы тонкого клиента, удалив папки с буквенно-цифровыми именами по путям:

%LOCALAPPDATA%\1C\1cv8\
%APPDATA%\1C\1cv8\

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