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

← На главную

Процедура «Тестирование и исправление информационной базы» (ТИИ) со всеми включенными опциями выполняет масштабную перестройку таблиц базы данных. Нередко после завершения этой операции пользователи сталкиваются с резким падением производительности: формы документов, справочников и подбора товаров открываются в разы дольше, а динамические списки зависают при построении.

Разберем подробно причины, по которым возникает подобная деградация, и пошагово рассмотрим методы восстановления нормальной скорости работы базы данных на связке 1С:Предприятие и PostgreSQL.

1. Сбор актуальной статистики и удаление мертвых строк (VACUUM ANALYZE)

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

Если после ТИИ оптимизатор запросов СУБД не получил свежей статистики, он строит неоптимальные планы выполнения (например, использует полное сканирование таблицы Seq Scan вместо эффективного индексного поиска). Для исправления ситуации выполним полную очистку и обновление статистики базы данных:

Остановим регламентные задания или выделим технологическое окно, когда пользователи отключены от информационной базы.
Подключимся к СУБД PostgreSQL и запустим монопольную операцию полной очистки и сбора статистики: VACUUM FULL ANALYZE;
Обратите внимание: команда VACUUM FULL блокирует обрабатываемые таблицы эксклюзивно и требует свободного дискового пространства, равного размеру перезаписываемых таблиц.

Если монопольное обслуживание выполнить невозможно, запустим оперативный сбор статистики без блокировки чтения и записи:

ANALYZE VERBOSE;

2. Настройка параметров фонового автовакуума (autovacuum)

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


autovacuum_naptime = 20s
autovacuum_vacuum_scale_factor = 0.01
autovacuum_analyze_scale_factor = 0.05
autovacuum_max_workers = 4

После изменения параметров перезагрузим конфигурацию PostgreSQL с помощью команды pg_reload_conf() или перезапуска службы СУБД.

3. Проверка периода рассчитанных итогов регистров накопления

Рассмотрим причину, которая часто скрывается на стороне самой платформы 1С. Во время выполнения ТИИ при операции «Пересчет итогов» период актуальности рассчитанных итогов по регистрам остатков (в конфигурациях «Управление торговлей», ERP или КА это регистры «Товары на складах», «Свободные остатки») может сместиться на дату самых ранних документов или сброситься.

Когда пользователь открывает форму подбора или документ продажи, динамический список обращается к виртуальным таблицам остатков. Если итоги не зафиксированы на текущую дату, платформа рассчитывает их «на лету» путем полного сканирования таблицы движений с момента последнего среза, что приводит к десятикратному падению скорости.

Разберем по шагам, как исправить расчет итогов:

Откроем информационную базу в режиме «Предприятие» под учетной записью с административными правами.
Перейдем в раздел Функции для технического специалиста (или «Все функции») и откроем стандартную обработку Управление итогами и агрегатами.
Установим период рассчитанных итогов вперед относительно текущей даты — на конец текущего или следующего месяца.
Для высоконагруженных регистров накопления проверим и включим флаг Разделение итогов.

Установить период итогов программно можно с помощью выполнения следующего фрагмента кода:


РегистрыНакопления.ТоварыНаСкладах.УстановитьПериодРассчитанныхИтогов(КонецМесяца(ТекущаяДатаСеанса()));

4. Диагностика прав доступа и пересчет ключей доступа (RLS / БСП)

Проанализируем влияние механизмов ограничения прав доступа на уровне записей (RLS). Полное тестирование и исправление затрагивает служебные таблицы Библиотеки Стандартных Подсистем — регистры КлючиДоступаКОбъектам, КлючиДоступаКРегистрам и ТаблицыГруппДоступа.

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

Откроем проблемную форму под пользователем с полными правами (где RLS отключен). Если форма открывается мгновенно, причина заключается в механизме прав доступа.
Перейдем в раздел Администрирование → Настройки пользователей и прав → Группы доступа.
Запустим регламентную процедуру обновления доступа на уровне записей или обновим ключи доступа вручную через служебные инструменты БСП.

5. Очистка системного каталога PostgreSQL (pg_catalog)

Опция реструктуризации таблиц при ТИИ создает, переносит и удаляет множество физических таблиц и индексов. Это приводит к раздуванию системных каталогов СУБД (pg_class, pg_attribute, pg_depend, pg_index). В результате планировщик тратит ощутимое время только на парсинг каждого нового запроса.

Выполним регламентное обслуживание системных таблиц каталога в консоли СУБД:


VACUUM FULL pg_catalog.pg_class;
VACUUM FULL pg_catalog.pg_attribute;
VACUUM FULL pg_catalog.pg_index;
VACUUM FULL pg_catalog.pg_depend;

6. Сброс зависших планов запросов и пула соединений

Процессы rphost сервера 1С:Предприятие удерживают постоянный пул соединений к СУБД и кэшируют скомпилированные параметризованные планы запросов (prepared statements). Даже если в PostgreSQL выполнено обновление статистики, сервер 1С может продолжать отправлять запросы по старым планам.

Для гарантированного применения новой статистики выполним перезапуск службы кластера серверов 1С (srv1cv8). Это очистит кэш планов выполнения и заставит оптимизатор PostgreSQL перестроить оптимальные планы выборки данных для всех динамических списков.

7. Оптимизация параметров планировщика PostgreSQL для 1С

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

Повышение детализации статистики: установим default_statistics_target = 500 или 1000 (вместо стандартного значения 100), после чего повторно выполним команду ANALYZE. Это позволит планировщику точнее оценивать количество строк в сложных выборках с подбором.
Ограничение перебора вариантов соединений: проверим параметры from_collapse_limit = 8 и join_collapse_limit = 8, чтобы планировщик не зависал при генерации планов для многотабличных запросов БСП.
Стоимость произвольного чтения: при использовании современных SSD/NVMe-дисков убедимся, что параметр random_page_cost находится в диапазоне от 1.1 до 1.5, предотвращая ошибочный выбор медленного Seq Scan.