Бывают случаи, когда процесс rphost отъедает много ОЗУ (Иногда даже всю свободную).
Как правило, это происходит при аварийном завершении работы процесса (случается утечка) или конечно, неоптимальный код приводит к таким последствиям.
В результате, даже соседним процессам «Сервера 1С» ее может не хватать, как и всем остальным процессам на данном сервере (особенно если на борту уже есть MS SQL, сервер терминалов, веб сервер и прочие).
К слову, подобные вещи уже давно происходят и с MS SQL, чьи аппетиты не редко приходится усмирять администраторам.
Собственно борьбой с утечками памяти мы и будем заниматься в сегодняшней статье.
Разберем различные способы, которые позволяют решить проблему «утечек» памяти rphost – а.
В 1С признают официально, что утечки памяти есть (на техническом уровне), и проблема не решена. Обещают решить с выходом версии 8.3.20. Также есть надежда, что с выходом 8.3.20 решат и в целом проблему повышено потребления памяти процессами 1С.
На «Сервер 1С» к сожалению, не все так просто как с MS SQL, здесь есть и ограничения версии «ПРОФ», и новые версии платформы. К примеру с 8.3.15 убрали возможность настройки «Допустимый объем памяти», что дополнительно давало нам возможность самим влиять на потребление памяти одного rphost-а. Некоторые настройки перенесли в «Параметры рабочего сервера».
Правда, обещают, что с версии 8.3.20 вернут обратно некоторые настройки регулирования потребления ОЗУ и для версии «ПРОФ», так как на сегодня, это возможно сделать, только используя «КОРП».
В 1С также временами не могут определиться, что оставить в «ПРОФ» а что перенести в «КОРП»:
Что также здорово «запутывает» пользователя.
Но и это еще не все )
Многие эксперты утверждают, что настроек «Сервера 1С» по умолчанию вполне достаточно, и что «Сервер 1С» не надо перезапускать.
Это утверждение только отчасти является верным!
Настройки «по умолчанию» имеют право быть, если действительно нет утечек памяти и других критических проблем, «Сервер 1С» не вылетает с ошибками и тд.
А утечки случаются и при небольших нагрузках (на «ПРОФ») и они как минимум могут требовать перезапуска рабочих процессов (rphost) так и более тонких настроек.
Правдой является и то, что перезапуск целого «Сервера 1С» не является «острой» необходимостью, так как корректного перезапуска rphost-а почти всегда достаточно, чтоб освободить память, и не навредить пользователям, которые в этот момент могут работать в 1С Предприятии.
Перезапуск «Сервера 1С» делаем только когда это действительно необходимо.
(К примеру, разово, в начале расследования утечки памяти).
Далее будет достаточно перезапуска rphost.
В разы же возрастает необходимость внесения правок, если у нас «КОРП»!
Есть высоконагруженные системы, где работают сотни пользователей, тогда действительно требуется чаще вносить изменения в параметры руками на «Сервере 1С», сюда и создание отказоустойчивого кластера, путем добавления «Рабочего сервера», также настройка, направленная на борьбу с утечками памяти (они встречаются и в «КОРП») а их в кластере будет еще больше.
А вот что касается части настроек с целью повысить как то производительность «Сервера 1С» (Не учитывая создания отказоустойчивого кластера серверов 1С), то вот здесь настройки как для «ПРОФ» так и «КОРП» будут малоэффективные.
Сервер 1С и так работает на максимум своих возможностей и фактически редко когда такие настройки могут быть действительно полезны. Усилия с целью повышения производительности стоит направить только на поддержание условий его работы, выделив достаточные аппаратные ресурсы.
Что ж, глубину проблемы мы с вами уяснили, теперь начинаем «распутывать».
Сперва разберемся, какое потребление rphost считать за нормальное.
Если говорить прямо, то сегодня на один RPHOST уже уходит больше 4ГБ ОЗУ.
В более старых конфигурациях 1С, эта цифра может быть меньше, а вот в новых (особенно ERP и подобных «тяжелых») , 10 -15 и больше ГБ, уже будет за норму.
ВАЖНО!
Напрасно надеется, что «Серверу 1С» хватит пары Гб, что остались у вас свободны, и тут никакие оптимизации не спасут!
Что в основном влияет на потребление ОЗУ процессом rphost:
- Количество сеансов
- Конфигурации 1С
- КОД (Качество написания)
- Фоновые задачи (Порожденные регламентными заданиями).
- Версия платформы 1С
Первое что стоит сделать в борьбе с утечкой:
Останавливаем «Сервер 1С», и очистим кэш на «Сервере 1С»!
И затем после его запуска в «боевых» условиях мы посмотрим на потребление ОЗУ в течение короткого времени от 30 мин до ~часа.
В этот период (30 мин – час) все пользователи (или около того) должны работать в 1С Предприятии, и мы увидим более-менее реальное потребление rphost-ов.
Бывает, что rphost чрезмерно потребляет ОЗУ не сразу, а на протяжении всего рабочего дня или даже нескольких дней. (Можно увидеть «утечку»).
После чего надо пройтись по сеансам!
С них я и всегда предлагаю начинать расследование, так как именно ошибки (не оптимально написанный код) чаще всего и вызывает «утечки».
Находим показатель
Память (текущая) в сеансах.
Это объем переданных и полученных данных с момента начала клиентского соединения (в байтах).
Отсортируем по наивысшим показателям эти сеансы, после чего стоит пристально разобрать у пользователей, где на сеанс ушло больше всего ОЗУ, что они делают в этот момент в 1С, какие отчеты, документы, обработки запускают.
Затем получив список объектов, мы проводим их диагностику на уровне кода в конфигурации, конечно с привлечением программиста 1С.
Если после анализа, качество кода конфигурации 1С не вызывает у вас сомнения (разобрали что происходит в сеансах пользователей), тогда это и будет «обычное» (или близкое к этому) потребление RPHOST-ов ОЗУ у Вас.
В том случаи, если вместо «приложения» у вас «фоновая задача» кушает много ОЗУ, следует разобрать ее.
Если автор «фонового» известен, тогда поиск проблемы будет сильно упрощен, нам останется только отключить регламентные задачи, которые породили «фоновое задание», что у нас и имеет сильное потребление. (Вкладка Администрирование – Регламентные и фоновые задания).
Если вместо пользователя у вас автор «фоновой задачи» «DefUser» или трудно, поймать, кто запускает «фоновую задачу».
Тогда можно пойти другим путем и в целом на «Сервере 1С» установить «Блокировку регламентных задач» после чего перезапустить «Сервер 1С».
Конечно, совет будет вредным если рег. задания у вас в конфигурации нужны!
Далее рассмотрим случай, когда явно есть «утечка памяти», а разбор кода и отключение регламентных задач не решили проблему:
Обычно в этом случаи администраторы выполняют перезапуск «Сервера 1С», прямо скажем не очень хорошая идея, особенно когда это происходит посреди рабочего дня.
Более правильно, но только для «Аврала» ) будет установка «интервала перезапуска» в свойствах локального кластера:
Установив 86400 секунд, мы автоматизируем процесс перезапуска рабочего процесса раз в сутки (Ночью).
Сделайте настройку так, чтоб не попасть в рабочее время!
Конечно, это не решит проблему «утечки» но с симптомом позволит бороться, это на тот случай если у вас абсолютно нет времени предпринять что-то более изящное.
Раз уж мы заговорили о более правильном способе, то он состоит из настроек на перезапуск rphost-a в свойствах «Параметры рабочего сервера» (Только для КОРП!).
Как на картинке выше установим значение «Временно допустимый объем памяти процессов» в байтах (у нас это 15 ГБ).
И интервал превышения допустимого объема памяти процесса 300 сек.
Что будет происходить после установки значений выше:
Зарегистрируйтесь, чтоб продолжить чтение статьи
Зарегистрироваться / Войти
Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>
С уважением, Богдан.
