← На главную

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

1. Диагностика однопоточной производительности и энергосбережения CPU

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

Для устранения аппаратных задержек выполним следующие настройки:

1. Настройка BIOS/UEFI: Переведем профиль управления питанием сервера в режим максимальной производительности (Static High Performance). Обязательно отключим энергосберегающие состояния процессора C-States (C1E, C3, C6) и технологии динамического снижения частоты Intel SpeedStep (EIST) / AMD Cool'n'Quiet, чтобы ядра не сбрасывали частоту в моменты коротких пауз между транзакциями.
2. Настройка схемы питания Windows Server: Перейдем в панель управления электропитанием и выберем схему «Высокая производительность» (High Performance). В дополнительных параметрах проверим, чтобы минимальное и максимальное состояние процессора были зафиксированы на значении 100%.
3. Отключение парковки ядер (Core Parking): По умолчанию Windows Server паркует неактивные ядра многопроцессорных систем. Включение запаркованного ядра занимает миллисекунды, что создает постоянные микрозадержки при обработке запросов 1С. Для полного отключения парковки зафиксируем параметр CPMMinCores на уровне 100%.

2. Учет архитектуры NUMA на двухпроцессорных серверах

Если в сервере установлено два физических процессора, память разделена на NUMA-узлы (Non-Uniform Memory Access). Когда процесс кластера rphost.exe или процесс СУБД postgres.exe обращается к оперативной памяти, физически подключенной к соседнему сокету, обращение идет через межпроцессорную шину UPI/QPI, что резко увеличивает задержки доступа к данным.

Рассмотрим методы оптимизации под NUMA:

1. В настройках BIOS проверим режим распределения памяти. Если сервер обслуживает параллельно и СУБД, и сервер 1С, рекомендуется активировать раздельные NUMA-ноды без принудительного перемежения памяти (Node Interleaving = Disabled).
2. Разнесем тяжелые процессы по разным сокетам: например, закрепим процессы PostgreSQL за ядрами первого процессора (NUMA-узел 0), а рабочие процессы 1С — за ядрами второго процессора (NUMA-узел 1), используя привязку соответствия процессоров (CPU Affinity).

3. Тонкая настройка конфигурации PostgreSQL для 1С

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

1. Синхронная фиксация транзакций: Установим synchronous_commit = off. По умолчанию СУБД сбрасывает журнал предзаписи (WAL) на диск при каждом завершении транзакции. Отключение синхронного сброса ускоряет запись документов в десятки раз, сохраняя целостность базы данных даже при сбое питания.
2. Оптимизация планов сложных запросов платформы:
   Скопировать код

   
   join_collapse_limit = 20
   from_collapse_limit = 20
   row_security = off
   

   Это заставляет оптимизатор запросов PostgreSQL строить эффективные планы для тяжелых динамических запросов, генерируемых платформой 1С.
3. Подключение специализированных модулей: В сборках PostgreSQL, адаптированных для 1С, добавим в параметр shared_preload_libraries модули online_analyze и plantuner. Они обеспечивают автоматический сбор статистики по временным таблицам, которые активно создаются в процессе работы 1С.
4. Управление контрольными точками (Checkpoints):
   Скопировать код

   
   checkpoint_timeout = 15min
   checkpoint_completion_target = 0.9
   

   Такие параметры сглаживают нагрузку на дисковую подсистему и предотвращают резкие зависания системы при сбросе «грязных» страниц памяти на диск.
5. Выделение памяти: Установим shared_buffers в размере 25% от общего объема оперативной памяти сервера (для 128 GB это 32 GB), а параметр temp_buffers = 256MB. Обратите внимание: значения в конфигурации чувствительны к регистру единиц измерения (MB, GB).

4. Исключения антивируса и дисковая подсистема

Постоянное сканирование транзакционных логов СУБД и временных файлов кластера 1С антивирусными мониторами или встроенным Windows Defender приводит к катастрофическому падению дисковой скорости.

Добавим в список обязательных исключений антивируса:

1. Исполняемые процессы: ragent.exe, rmngr.exe, rphost.exe, postgres.exe.
2. Каталоги баз данных PostgreSQL (папки base, pg_wal / pg_xlog).
3. Служебный каталог кластера серверов 1С (папка srvinfo) и временные каталоги пользователей и службы Temp.

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

При переносе сразу нескольких баз конфигураций (УНФ, ЗУП, Бухгалтерия) на один сервер платформа запускает фоновые регламентные задания (индексация полнотекстового поиска, расчет итогов, загрузка курсов валют, проверка контрагентов) для каждой базы одновременно. Это создает постоянную фоновую конкуренцию за блокировки и ресурсы СУБД.

Через консоль администрирования кластера серверов 1С или конфигуратор необходимо отключить неиспользуемые регламентные задания во всех перенесенных базах либо разнести время их запуска на ночные часы.