Почему подтормаживает интерфейс 1С на сервере PostgreSQL под Windows и как это исправить?

При переходе с файловых баз или MS SQL на PostgreSQL в среде Windows администраторы нередко сталкиваются с микрозадержками в управляемом интерфейсе 1С: подвисанием списков при прокрутке в начало или конец, паузами при закрытии форм документов и повышенной загрузкой процессора до 90–100%. Разберем по шагам, почему возникают подобные симптомы и как комплексно оптимизировать связку 1С:Предприятие и PostgreSQL.

1. Настройка планов регламентного обслуживания базы данных

В отличие от файлового режима, в СУБД PostgreSQL критически важно регулярно обновлять статистику и очищать базу от устаревших версий строк (dead tuples). Без актуальной статистики планировщик СУБД строит неоптимальные планы выполнения запросов динамических списков, что приводит к полному сканированию таблиц (Seq Scan) вместо использования индексов.

Рассмотрим скрипт для регулярного обслуживания базы через утилиту psql:

SET PGPASSWORD=ВашПароль
"C:\Program Files\PostgreSQL\9.6.3-1.1C\bin\psql.exe" --dbname=ИмяБазы --host=127.0.0.1 --port=5432 --username=postgres --command="reindex DATABASE ИмяБазы;"
"C:\Program Files\PostgreSQL\9.6.3-1.1C\bin\psql.exe" --dbname=ИмяБазы --host=127.0.0.1 --port=5432 --username=postgres --command="vacuum full analyze;"

Обратите внимание: команду VACUUM FULL необходимо запускать во внерабочее время, так как она накладывает исключительную блокировку на таблицы.

2. Управление электропитанием процессора и аппаратные настройки

Одной из частых причин просадки производительности является работа процессора в энергосберегающем режиме. Клиент-серверное взаимодействие 1С работает по принципу «пинг-понга»: процессор то загружен сервером 1С, то простаивает в ожидании ответа СУБД. При активных энергосберегающих технологиях процессор постоянно сбрасывает и повышает тактовую частоту, работая на заниженных частотах.

Проанализируем необходимые настройки аппаратной части и операционной системы:

1. Профиль электропитания в Windows: откроем панель управления электропитанием и выберем схему «Высокая производительность». В дополнительных параметрах проверим, чтобы минимальное и максимальное состояние процессора были выставлены в 100%.
2. Настройки BIOS/UEFI: отключим энергосберегающие состояния C-States и C1E, включим режим постоянной максимальной производительности и активируем Turbo Boost.
3. Ограничения дисковой подсистемы: использование программного RAID (FakeRAID) без аппаратного контроллера с энергонезависимой памятью (BBU) увеличивает задержки записи при транзакциях и нагружает центральный процессор. Для серверных баз рекомендуется размещать данные и журналы транзакций на высокоскоростных накопителях NVMe/SSD.

3. Тонкая настройка конфигурационного файла postgresql.conf

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

1. Статистика планировщика: параметр default_statistics_target рекомендуется установить в диапазоне от 1000 до 5000. Это позволяет планировщику точнее оценивать распределение данных в таблицах 1С.
2. Параметры объединения таблиц: для платформы 1С рекомендуется задать join_collapse_limit = 1 и from_collapse_limit = 1, чтобы оптимизатор не тратил лишние циклы CPU на перебор вариантов соединения таблиц, уже скомпонованных платформой.
3. Параллельные процессы: отключим параллелизм для отдельных запросов параметром max_parallel_workers_per_gather = 0, чтобы избежать лишней конкуренции за потоки CPU при множестве мелких транзакций.
4. Балансировка памяти: выделим shared_buffers (обычно 25% от доступной RAM для СУБД) и настроим effective_cache_size (до 50–75% от объема выделенной СУБД памяти). Для предотвращения вытеснения в своп при одновременной работе нескольких десятков баз параметр work_mem следует держать в разумных пределах (32MB–128MB).
5. Модули расширения: при высокой фоновой загрузке процессора проверим влияние параметров online_analyze.enable и plantuner. Их временное отключение на тестовом стенде позволяет оценить высвобождение вычислительных ресурсов.

4. Оптимизация регламентных и фоновых заданий в кластере 1С

Если на одном сервере размещено множество информационных баз (например, 10–15 баз), типовые регламентные задания (индексация полнотекстового поиска, загрузка курсов валют, обновление классификаторов, расчет итогов) начинают запускаться одновременно, создавая пиковую нагрузку на все ядра процессора.

Выполним следующие действия по оптимизации регламентных заданий:

1. В консоли администрирования кластера серверов 1С:Предприятия откроем свойства неиспользуемых, архивных или тестовых баз и установим флаг «Блокировка регламентных заданий включена».
2. В рабочих базах перенесем тяжелые задания (слияние индексов полнотекстового поиска, закрытие месяца, расчет итогов) на ночные часы.
3. В свойствах кластера настроим параметры рабочих процессов: ограничим количество баз и сеансов на один рабочий процесс rphost, чтобы локализовать нагрузку.

5. Проверка антивируса и клиентского кэша

Задержка при закрытии форм документов часто связана с синхронной записью персональных настроек пользователя в системные таблицы ХранилищеСистемныхНастроек и обращением к локальному дисковому кэшу.

Проверим настройки безопасности на сервере и клиентских машинах:

1. Добавим в исключения антивируса и Защитника Windows каталоги СУБД (директорию data PostgreSQL), каталог кластера серверов 1С (srvinfo), а также системные временные папки %TEMP%.
2. На клиентских рабочих станциях очистим локальный кэш конфигураций (папки в %LOCALAPPDATA%\1C\1cv8 и %APPDATA%\1C\1cv8), повреждение которого может вызывать зависания управляемых форм при открытии и закрытии.