В процессе эксплуатации высоконагруженных систем на платформе 1С:Предприятие 8.3 многие технические специалисты столкнулись с критической проблемой: лавинообразный рост потребления оперативной памяти рабочими процессами rphost. Проблема локализуется в моменты массового формирования электронных подписей. Рассмотрим подробно, почему это происходит и как стабилизировать работу сервера.
Проанализируем типовой сценарий. При выполнении серверного кода, использующего объект МенеджерКриптографии, а именно его метод Подписать(), система обращается к установленному на сервере криптопровайдеру (например, CryptoPro CSP). Выясним причину аномального поведения: при каждом вызове метода платформа выделяет блок памяти (порядка 100–150 МБ) под криптографический контекст. Однако из-за внутренней ошибки управления ресурсами этот блок не освобождается после завершения операции.
В результате, если нам требуется подписать пакет из 100 документов в одном сеансе, потребление памяти процессом rphost может вырасти на 10–15 ГБ за считанные минуты. Это неизбежно приводит к срабатыванию механизмов защиты кластера, принудительному завершению рабочих процессов и прерыванию работы пользователей. Ошибка официально зафиксирована в реестре под номером 80016625.
Наиболее правильным и надежным способом решения является установка версии платформы, в которой данная ошибка была исправлена на уровне программного ядра (C++). Разберем по шагам, на какие релизы стоит ориентироваться:
8.3.24.1691 или выше.8.3.25.1546.После обновления платформы принудительная очистка памяти будет происходить корректно сразу после завершения области видимости переменной МенеджерКриптографии.
Если оперативное обновление серверной платформы невозможно (например, из-за жесткого регламента или необходимости тестирования зависимых систем), рассмотрим архитектурный обходной путь — подписание на клиенте. Суть метода заключается в том, что нагрузка по взаимодействию с криптопровайдером перекладывается с серверного процесса rphost на клиентское приложение (тонкий клиент).
Важный нюанс: даже если на клиенте возникнет утечка, она затронет только конкретный сеанс пользователя и не приведет к падению всего сервера. Проанализируем пример кода для асинхронного подписания на клиенте, который работает стабильнее:
&НаКлиенте
Асинхрон Процедура ПодписатьДокументНаКлиенте(ДанныеДляПодписи, Сертификат)
Менеджер = Новый МенеджерКриптографии("", "", 80); // Тип провайдера для ГОСТ 2012
Менеджер.ПарольДоступаКЗакрытомуКлючу = "ВашПароль";
Попытка
Результат = Ждать Менеджер.ПодписатьАсинхрон(ДанныеДляПодписи, Сертификат);
// Дальнейшая логика обработки подписи
Исключение
Сообщить("Ошибка при подписании: " + ОписаниеОшибки());
КонецПопытки;
Менеджер = Неопределено; // Явное обнуление ссылки
КонецПроцедуры
Использование асинхронных методов (ПодписатьАсинхрон) позволяет более эффективно задействовать сборщик мусора платформы.
В качестве временной меры («костыля») до момента обновления можно настроить параметры кластера 1С так, чтобы процессы rphost завершались автоматически при достижении критического порога. Посмотрим, как это сделать:
Это не устранит утечку, но позволит серверу «выживать», автоматически перезапуская «раздувшиеся» процессы.
Проанализируем влияние версии криптопровайдера. Хотя основной виновник — платформа 1С, версия CryptoPro CSP 5.0 R2/R3 ведет себя более предсказуемо в плане освобождения дескрипторов. Если вы используете устаревшую 4-ю версию, крайне рекомендуется рассмотреть переход на 5.0. Также обратите внимание на настройку типа провайдера в коде 1С:
Type 80.Type 75.Несоответствие типа провайдера в объекте МенеджерКриптографии и установленного в системе ПО может провоцировать дополнительные ошибки выделения памяти.
Подведем итог. Если ваша информационная база активно использует ЭДО и вы заметили рост потребления ОЗУ на сервере, в первую очередь проверьте номер сборки платформы. Обновление до 8.3.25.1546 или 8.3.24.1691 является единственным полноценным решением проблемы. Если обновление откладывается, используйте клиентское подписание и настройте лимиты памяти в консоли администрирования кластера.