← На главную

При переходе на платформу 1С:Предприятие версии 8.3.11 многие администраторы и пользователи сталкиваются с резким падением производительности. Процесс rphost начинает критически загружать ядро процессора на 100% при выполнении стандартных операций: открытии форм, отчетов или инициализации схем компоновки данных, например при исполнении кода ОтчетОбъект.СхемаКомпоновкиДанных = СхемаКД. При этом сервер СУБД MS SQL или PostgreSQL остаётся практически незагруженным.

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

Причины падения производительности в 8.3.11

Рассмотрим подробно, почему версии 8.3.10 и более ранние работали быстро на той же конфигурации и серверном оборудовании, а 8.3.11 вызывает длительные задержки:

1. Переход на новый стандарт C++ и замена STL-библиотек. Начиная с версии 8.3.11, разработчики 1С отказались от библиотеки STLPort (которая использовалась в файле stl83.dll) и перевели платформу на стандартные библиотеки рантайма C++ (Universal CRT). Новые алгоритмы десериализации метаданных и работы с контейнерами памяти требуют большей производительности процессора.
2. Использование старых операционных систем (Windows Server 2003). В устаревших ОС компоненты Visual C++ Redistributable 2015 работают через слой эмуляции совместимости без поддержки современных оптимизаций системных вызовов. Это приводит к существенным задержкам при парсинге XML-контейнеров и инициализации форм.
3. Однопоточная обработка структур метаданных. Процесс десериализации схем СКД, создание сложных управляемых форм и разбор конфигурации в процессе rphost выполняются строго в один поток процессора. На многоядерных серверах со слабой производительностью на одно ядро (например, старые процессоры Xeon) время выполнения одиночного вызова возрастает в разы.
4. Переполнение и частый сброс кэша 32-разрядного rphost. Рабочий процесс 32-битной платформы ограничен 2–4 ГБ адресного пространства. При возросшем объеме внутренних структур в 8.3.11 процесс быстро исчерпывает память, начинает сбрасывать кэш и аварийно перезапускаться, заставляя пользователей ожидать повторной загрузки метаданных.

Способ 1. Настройка параметров кластера и рабочих процессов rphost

Если используется 32-разрядный сервер 1С, необходимо правильно ограничить использование памяти для процессов rphost, чтобы предотвратить их зависание при постоянных перезапусках.

Разберем по шагам порядок настройки в консоли администрирования кластера серверов 1С:

1. Откроем консоль администрирования кластера серверов 1С:Предприятие.
2. Перейдем в свойства кластера и настроим разделение нагрузки: укажем запуск нескольких процессов rphost (из расчета не более 1,5–2 ГБ ОЗУ на один процесс).
3. Установим параметр Допустимый объем памяти для рабочих процессов, чтобы перезапуск происходил контролируемо до момента критического падения скорости работы.
4. Установим интервал времени для безопасного обновления рабочих процессов без обрыва пользовательских сеансов.

Способ 2. Вынос сервера приложений на современную ОС

Так как основная причина критических затупов связана с работой компонентов C++ в среде Windows Server 2003, эффективным решением является вынос службы сервера 1С (процессы ragent, rmngr, rphost) на операционную систему не ниже Windows Server 2012 / Windows 10.

Выясним, как это реализовать с минимальными затратами:

1. Сервер базы данных MS SQL Server и пользовательские RDP-сеансы можно оставить на существующей машине.
2. Установим серверную службу 1С:Предприятие на отдельный компьютер или виртуальную машину с современной ОС.
3. Перенесем программные или аппаратные ключи защиты 1С на новый сервер приложений.
4. В консоли кластера перенаправим подключение к существующей базе данных на сервере СУБД.

Способ 3. Переход на 64-разрядную платформу 1С

При работе с крупными конфигурациями на базе Библиотеки Стандартных Подсистем (БСП), такими как ЗУП 3, БП 3 или ERP, 32-битный процесс rphost не справляется с объемом памяти. Переход на 64-битный сервер 1С снимет лимит в 4 ГБ ОЗУ на процесс и позволит платформе задействовать 64-разрядные инструкции процессора.

Посмотрим на последовательность действий:

1. Приобретем лицензию на 64-разрядный сервер 1С:Предприятие.
2. Установим 64-битную версию платформы на серверную ОС x64.
3. Проверим работу регламентных заданий и тяжелых отчетов — задержки при повторных обращениях к метаданным исчезнут за счет полноценного кэширования в ОЗУ.

Способ 4. Прогрев кэша и оптимизация фоновых заданий

Чтобы пользователи не сталкивались со стопроцентной загрузкой процессора при первом открытии отчетов и журналов документов, организуем автоматический «прогрев» кэша метаданных.

Рассмотри основные рекомендации по оптимизации:

1. Настроим регламентное задание, которое запускается сразу после старта службы 1С или ночью и выполняет программный вызов основных форм, отчетов и схем компоновки данных. Это занесет скомпилированные структуры в RAM до начала рабочего дня.
2. Отключим или перенесем на нерабочее время индекс полнотекстового поиска (ППД). Фоновое обновление индекса в 8.3.11 создаёт высокую пиковую нагрузку на CPU параллельно с пользовательскими сеансами. Для отключения зайдём в программу с правами администратора и откроем форму Управление полнотекстовым поиском, где снимем активность фонового индексирования.

Важное примечание: Если инфраструктурные изменения временно недоступны, а конфигурации не требуют обязательного использования релизов 8.3.11, наиболее стабильным техническим решением будет временный откат на версию платформы 8.3.10 (например, 8.3.10.2580/8.3.10.2699), в которой используется прежний механизм работы с библиотеками C++.