Rphost что за служба
rphost или рабочий процесс 1С 8.3
rphost.exe — это рабочий процесс 1С 8.3, который обслуживает клиентские обращения и взаимодействует с сервером базы данных. rphost — важнейшее звено архитектуры 1С предприятия, которое берёт на себя достаточно большую аппаратную нагрузку. Таких процессов может быть большое количество, и они могут быть разнесены по разным машинам.
Очень часто администраторы жалуются на то, что rphost.exe «жрёт память» и сильно грузит процессор. Посмотреть, сколько в данный момент расходуется памяти, можно в обычном диспетчере задач:
Инструмент для администрирования рабочих процессов — утилита, входящая в поставку сервера 1С, называется Администрирование серверов 1С Предприятия (или консоль кластера):
С помощью данной утилиты можно также управлять и отслеживать другие вещи:
Настройки рабочего процесса
Рассмотрим нюансы настройки в 1С:
На платформе 1С 8.3 количеством рабочих процессов управляет кластер серверов самостоятельно.
К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.
rphost занимает память и грузит процессор
У многих возникают проблемы с rphost.exe, разного вида:
причем 1С даже на запущена, а в диспетчере следующее:
ежеминутно расчет на 2-3 мегабайта.
Как быть и что делать?
Решение проблем с rphost
Он работает- выполняя фоновые задания:
Есть несколько вариантов решения:
1. Обновить платформу 1С и поддерживайте ее в актуальном состоянии
2. Перезапустить сервер или службу Агент 1С Предприятия, но это временное лечение.
3. Отключить выполнение фоновых заданий (но тогда часть операции заложенных в программу не будет выполнено)
Отключить можно в свойствах базы
Установите галку Блокировка регламентных заданий включена и нажмите ОК
Для типовых конфигураций советую отключить обновление Полнотекстового поиска:
4. В консоли администрирования в настройках кластера выставить предел ОП и периодичность перезапуска рабочих процессов
Установим следующие параметры для рабочих процессов:
Подробнее об этом я уже писал в статье Оптимальные параметры кластера 1С 8.3
После установки таких настроек кластера, сервер начал стабильно работать.
rphost занимает память и грузит процессор
У многих возникают проблемы с rphost.exe, разного вида:
причем 1С даже на запущена, а в диспетчере следующее:
ежеминутно расчет на 2-3 мегабайта.
Как быть и что делать?
Решение проблем с rphost
Он работает- выполняя фоновые задания:
Есть несколько вариантов решения:
1. Обновить платформу 1С и поддерживайте ее в актуальном состоянии
2. Перезапустить сервер или службу Агент 1С Предприятия, но это временное лечение.
3. Отключить выполнение фоновых заданий (но тогда часть операции заложенных в программу не будет выполнено)
Отключить можно в свойствах базы
Установите галку Блокировка регламентных заданий включена и нажмите ОК
Для типовых конфигураций советую отключить обновление Полнотекстового поиска:
4. В консоли администрирования в настройках кластера выставить предел ОП и периодичность перезапуска рабочих процессов
Установим следующие параметры для рабочих процессов:
Подробнее об этом я уже писал в статье Оптимальные параметры кластера 1С 8.3
После установки таких настроек кластера, сервер начал стабильно работать.
Процесс 1С rmngr.exe грузит процессор
Введение
Этот сервер привлек мое внимание сразу же, как только я стал с ним работать. Предыдущий администратор безрезультатно бился над производительностью, приобрел 2 внешних корзины для отдельного рейда под базы данных mssql и временные данные пользователя 1С, но существующую проблему по загрузке процессора это не решало, хотя немножко разгрузило диски, но реальная проблема была не в них.
На сервере размещались примерно 30-35 баз, в которых работали по 1-2 человека и пару баз были, где работали по 3-5 человек одновременно. Все это крутилось вместе с MSSQL сервером на отдельном железном сервере с одним стареньким ксеоном и 32 гб оперативы. В принципе, для этих задач железо было более чем.
Первое, на что я обратил внимание, это то, что процессор был загружен даже ночью, когда на сервере никто не работал. Полез в консоль администратора смотреть, что нагружает процессор. Оказалось, что это фоновые задачи. Для большинства баз они были не нужны и все лишнее отключил. Нагрузка процессора сразу упала до приемлемого уровня в 60-70%, а диски вообще полностью разгрузились. Я про сервер забыл на какое-то время.
Снова к нему вернулся, когда пользователи стали жаловаться на очень медленную работу баз 1С. Процессор к тому времени почти всегда был загружен на 100%. Лишних фоновых задач уже не было. Надо было разбираться более внимательно, в чем тут проблема.
Разбираемся что конкретно в rmngr.exe грузит процессор
Загрузку процессора в равной степени давал процесс rmngr.exe и rphost.exe. Rphost уже ранее был настроен и оптимизирован. Вот такие настройки дали стабильную работу без необходимости перезапускать сервер месяцами:
Нагрузку rphost давал за счет оставшихся фоновых задач и что с ним еще сделать, я не знал. А с rmngr хотелось разобраться и узнать, что конкретно пожирает процессорное время. В этом процессе собраны все процессы менеджера кластера:
Есть возможность разделить сервисы менеджера кластера по разным системным процессам rmngr.exe и по pid определить, какая именно служба нагружает процессор. Включить такое разделение можно в свойствах рабочего сервера:
После того, как вы поставите галку, агент сервера 1С сам перезапустится с новыми настройками. После этого в диспетчере задач у вас будет порядка 15-ти процессов rmngr.exe с разными pid. Смотрите, какой из процессов больше всего использует процессор и в консоли управления 1С в разделе Менеджеры кластера по pid смотрите описание процесса.
В моем случае это был сервис журнала регистраций. Чтобы это узнать, дважды щелкните мышкой по процессу с необходимым pid:
Пол дела сделали, нашли виновника тормозов. Я скрины делал, когда уже решил проблему, так что у меня нагрузки нет.
Сервис журнала регистраций 1С нагружает процессор
Я выяснил, что конкретно дает чрезмерную нагрузку на сервер. Посмотрел на объем журналов регистраций. У некоторых баз он достигал размера в 10-15 гигов. После чистки серверу стало заметно легче, нагрузка снова опустилась, но где-то до 80-90% и я на несколько месяцев забыл про сервер.
Он напомнил о себе тормозами и загрузкой процессора в 100%. Проделанные выше операции уже не давали результата. Баз стало немного больше и нужно было думать, как разгрузить сервер. Он работал на все 100% даже в нерабочее время, когда на нем не было ни одного реального пользователя. Сервис журнала регистраций потреблял 30-40% процессорного времени.
Я стал внимательно шерстить интернет на заданную тему и нашел несколько заметок. Находились люди, которые обратили внимание на чрезмерную нагрузку сервиса журнала регистраций. Как вариант решения проблемы они предлагали откатиться на старую версию ведения логов lgf вместо новой lgd. Я не знаю, что принципиально изменилось в формате ведения лога журнала регистраций, но по отзывам попробовавших, нагрузка на процессор падала. Забегая вперед скажу, что мне этот совет помог.
Переводим сервер на старый вариант ведения логов журнала регистраций
Какой-то одной настройки или автоматического решения для перевода лога журнала регистраций в старый формат lgf нет. Чтобы использовать старый формат необходимо остановить службу Агента Сервера 1С:Предприятия. Затем отправиться в папку C:\Program Files (x86)\1cv8\srvinfo\reg_1541, выбрать по id базу, в которой хотите изменить формат лога. У меня баз было много, мне лениво стало вручную в каждой менять формат. Я выбрал базы с самым большим объемом и изменил формат только у них.
В каждой папке с базой есть каталог 1Cv8Log, а в нем 2 файла: 1Cv8.lgd и 1Cv8.lgd-journal. Их надо удалить и вместо них в этой папке создать пустой файл 1Cv8.lgf. Проделать такую операцию нужно со всеми базами, где будете менять формат лога. Старый не обязательно удалять, лучше его перенести куда-нибудь, вдруг пригодятся записи из него.
После этого можно запускать службу Агента Сервера 1С:Предприятия. После перехода на старый формат журнала регистрации, нагрузка процесса rmngr.exe упала практически до 0, а сервера в целом до приемлемых 40-60%.
Заключение
После того, как вы решите все проблемы на сервере 1С, процессы менеджера кластера нужно снова объединить в 1, убрав отвечающую за этот параметр галку в свойствах рабочего сервера. 1С не рекомендует постоянно использовать такой режим работы, так как он является отладочным.
Утечка памяти в 1С Предприятии
Бывают случаи, когда процесс 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С» хватит пары Гб, что остались у вас свободны, и тут никакие оптимизации не спасут!
Что в основном влияет на потребление ОЗУ процессом rphost:
Первое что стоит сделать в борьбе с утечкой:
Останавливаем «Сервер 1С», и очистим кэш на «Сервере 1С»!
И затем после его запуска в «боевых» условиях мы посмотрим на потребление ОЗУ в течение короткого времени от 30 мин до
В этот период (30 мин – час) все пользователи (или около того) должны работать в 1С Предприятии, и мы увидим более-менее реальное потребление rphost-ов.
Бывает, что rphost чрезмерно потребляет ОЗУ не сразу, а на протяжении всего рабочего дня или даже нескольких дней. (Можно увидеть «утечку»).
После чего надо пройтись по сеансам!
С них я и всегда предлагаю начинать расследование, так как именно ошибки (не оптимально написанный код) чаще всего и вызывает «утечки».
Память (текущая) в сеансах.
Это объем переданных и полученных данных с момента начала клиентского соединения (в байтах).
Отсортируем по наивысшим показателям эти сеансы, после чего стоит пристально разобрать у пользователей, где на сеанс ушло больше всего ОЗУ, что они делают в этот момент в 1С, какие отчеты, документы, обработки запускают.
Затем получив список объектов, мы проводим их диагностику на уровне кода в конфигурации, конечно с привлечением программиста 1С.
Если после анализа, качество кода конфигурации 1С не вызывает у вас сомнения (разобрали что происходит в сеансах пользователей), тогда это и будет «обычное» (или близкое к этому) потребление RPHOST-ов ОЗУ у Вас.
В том случаи, если вместо «приложения» у вас «фоновая задача» кушает много ОЗУ, следует разобрать ее.
Если автор «фонового» известен, тогда поиск проблемы будет сильно упрощен, нам останется только отключить регламентные задачи, которые породили «фоновое задание», что у нас и имеет сильное потребление. (Вкладка Администрирование – Регламентные и фоновые задания).
Если вместо пользователя у вас автор «фоновой задачи» «DefUser» или трудно, поймать, кто запускает «фоновую задачу».
Тогда можно пойти другим путем и в целом на «Сервере 1С» установить «Блокировку регламентных задач» после чего перезапустить «Сервер 1С».
Конечно, совет будет вредным если рег. задания у вас в конфигурации нужны!
Далее рассмотрим случай, когда явно есть «утечка памяти», а разбор кода и отключение регламентных задач не решили проблему:
Обычно в этом случаи администраторы выполняют перезапуск «Сервера 1С», прямо скажем не очень хорошая идея, особенно когда это происходит посреди рабочего дня.
Более правильно, но только для «Аврала» ) будет установка «интервала перезапуска» в свойствах локального кластера:
Установив 86400 секунд, мы автоматизируем процесс перезапуска рабочего процесса раз в сутки (Ночью).
Сделайте настройку так, чтоб не попасть в рабочее время!
Конечно, это не решит проблему «утечки» но с симптомом позволит бороться, это на тот случай если у вас абсолютно нет времени предпринять что-то более изящное.
Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>