Проблема избыточного потребления оперативной памяти рабочими процессами rphost является одной из самых частых при эксплуатации серверов 1С. Процесс постепенно «набирает обороты», отнимая все больше ресурсов системы, что в конечном итоге может привести к деградации производительности или зависанию всего сервера. В этой статье мы подробно разберем, почему это происходит, и рассмотрим рабочие инструменты для контроля памяти, доступные как в версии КОРП, так и в ПРОФ.
Прежде чем переходить к настройкам, давайте проанализируем ситуацию и выясним, почему rphost захватывает память. Это не всегда связано с ошибками (утечками) в коде платформы или конфигурации. Рассмотрим основные факторы:
Рассмотрим основной механизм лечения — автоматический перезапуск рабочих процессов при достижении определенного лимита. В современных версиях платформы (начиная с 8.3.15) параметры контроля объема памяти были частично перенесены из КОРП-функционала в ПРОФ, что позволяет нам использовать их без дорогостоящих лицензий.
Для настройки нам необходимо открыть консоль администрирования кластера серверов 1С. Разберем ключевые параметры, которые находятся в свойствах рабочего сервера:
rphost.Важно не устанавливать значения «на глаз». Проанализируем пример расчета для сервера с 12 Гб оперативной памяти. Предположим, что в нормальном состоянии один процесс rphost занимает около 3 Гб.
Рассчитаем параметр Допустимый объем памяти по следующей формуле:
Лимит = Всего ОЗУ - ОЗУ для ОС - (Количество рабочих процессов * Средний рабочий объем)
Для нашего примера:
12 Гб (всего) - 2 Гб (на систему) - 3 Гб (запас под один rphost) = 7 Гб.
Почему мы оставляем запас? Рассмотрим алгоритм работы кластера при перезапуске:
rphost. На этом этапе в памяти одновременно находятся и старый (7 Гб), и новый (начальный объем).Если установить лимит слишком низким, сервер уйдет в бесконечный цикл перезапусков, что парализует работу пользователей.
Выясним причину споров о лицензиях. Хотя базовые лимиты теперь доступны в ПРОФ, некоторые продвинутые функции управления остаются прерогативой КОРП-версии:
В версии ПРОФ мы можем ограничить только общий объем памяти на весь процесс. Если один «жадный» отчет пользователя съест всю память, перезагрузятся все пользователи, работающие в данном rphost.
В версии КОРП доступны настройки:
Помимо настроек кластера, рекомендуется внедрить практику ежедневного обслуживания системы. Посмотрим на наиболее эффективные шаги:
Несмотря на наличие механизмов самоочистки в платформе, полная перезагрузка службы 1C:Enterprise Server (или всего сервера) раз в сутки (обычно ночью) остается «золотым стандартом». Это позволяет полностью очистить фрагментированную память и завершить зависшие сеансы, которые могли не закрыться штатно. Настроить это можно через обычный планировщик задач Windows и простой скрипт:
net stop "1C:Enterprise 8.3 Server Agent"
timeout /t 30 /nobreak
net start "1C:Enterprise 8.3 Server Agent"
Часто кажется, что память «ест» 1С, но на самом деле серверу 1С просто не хватает ОЗУ, потому что её захватил SQL Server. Проанализируем ситуацию: SQL по умолчанию старается забрать всю доступную память под свой буферный кэш. Необходимо в настройках SQL Server Management Studio (свойства сервера -> Memory) ограничить Maximum server memory, оставив операционной системе и процессам 1С как минимум 4–8 Гб (в зависимости от общей емкости).
В настройках кластера можно указать параметр Количество сеансов на рабочий процесс. Вместо одного огромного rphost на 100 пользователей, создайте 5 процессов по 20 пользователей. Это повысит отказоустойчивость: если один процесс превысит лимит и уйдет в перезагрузку, это затронет только 20% пользователей. Также операционной системе проще выделять память нескольким небольшим процессам, чем одному монолитному блоку.
Если память «улетает» за считанные часы, никакие настройки перезапуска не помогут — нужно искать причину в коде. Воспользуйтесь инструментом «Трассировка» или встроенным в платформу «Замером производительности». Обратите внимание на обработчики событий ПриКомпоновкеРезультата в отчетах и циклы, в которых создаются большие массивы или таблицы значений без их последующей очистки.
Подводя итог, скажем: лечение «прожорливости» rphost — это комплексный процесс. Сочетание грамотно рассчитанных лимитов в консоли кластера, ограничение аппетитов SQL-сервера и регулярные ночные перезапуски позволяют поддерживать стабильную работу системы даже на типовых конфигурациях без использования КОРП-лицензий.