rmngr exe что это
Процесс 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С не рекомендует постоянно использовать такой режим работы, так как он является отладочным.
rmngr.exe: что это? и как его убрать
В вашей системе запущено много процессов, которые потребляют ресурсы процессора и памяти. Некоторые из этих процессов, кажется, являются вредоносными файлами, атакующими ваш компьютер.
Чтобы исправить критические ошибки rmngr.exe,скачайте программу Asmwsoft PC Optimizer и установите ее на своем компьютере
Asmwsoft PC Optimizer — это пакет утилит для Microsoft Windows, призванный содействовать управлению, обслуживанию, оптимизации, настройке компьютерной системы и устранению в ней неполадок.
1- Очистите мусорные файлы, чтобы исправить rmngr.exe, которое перестало работать из-за ошибки.
2- Очистите реестр, чтобы исправить rmngr.exe, которое перестало работать из-за ошибки.
Как удалить заблокированный файл rmngr.exe.
3- Настройка Windows для исправления критических ошибок rmngr.exe:
Всего голосов ( 182 ), 115 говорят, что не будут удалять, а 67 говорят, что удалят его с компьютера.
Как вы поступите с файлом rmngr.exe?
Некоторые сообщения об ошибках, которые вы можете получить в связи с rmngr.exe файлом
(rmngr.exe) столкнулся с проблемой и должен быть закрыт. Просим прощения за неудобство.
(rmngr.exe) перестал работать.
rmngr.exe. Эта программа не отвечает.
(rmngr.exe) — Ошибка приложения: the instruction at 0xXXXXXX referenced memory error, the memory could not be read. Нажмитие OK, чтобы завершить программу.
(rmngr.exe) не является ошибкой действительного windows-приложения.
(rmngr.exe) отсутствует или не обнаружен.
RMNGR.EXE
Проверьте процессы, запущенные на вашем ПК, используя базу данных онлайн-безопасности. Можно использовать любой тип сканирования для проверки вашего ПК на вирусы, трояны, шпионские и другие вредоносные программы.
процессов:
Cookies help us deliver our services. By using our services, you agree to our use of cookies.
Архитектура кластера
Основные возможности кластера серверов
Общая схема клиент-серверного варианта работы
В клиент-серверном варианте работы клиентское приложение взаимодействует с кластером серверов, который, в свою очередь, осуществляет взаимодействие с сервером баз данных.
Один из компьютеров, входящих в состав кластера серверов, является центральным сервером кластера. Центральный сервер, помимо обслуживания клиентских соединений, управляет работой всего кластера и хранит реестр кластера.
Для клиентского соединения кластер адресуется по имени центрального сервера и номеру сетевого порта. Если используется стандартный сетевой порт, то достаточно указания одного имени центрального сервера.
При установке соединения клиентское приложение обращается к центральному серверу кластера. Центральный сервер, на основе анализа статистики загруженности рабочих процессов, направляет клиентское приложение к конкретному рабочему процессу, который будет его обслуживать. Этот процесс может находиться как на центральном сервере, так и на любом рабочем сервере кластера.
Рабочий процесс выполняет аутентификацию пользователя и обслуживает соединение до окончания сеанса работы клиента с данной информационной базой.
Состав простейшего кластера серверов
Простейший кластер серверов может располагаться на одном компьютере и содержать один рабочий процесс:
Функционирование компьютера в составе кластера обеспечивается процессом ragent.exe, который называется агентом сервера. Соответственно компьютер, на котором запущен агент сервера, называется рабочим сервером. Одной из функций агента сервера является ведение списка кластеров, расположенных на данном рабочем сервере.
Агент сервера и список кластеров не входят в состав кластера серверов, а лишь обеспечивают работу сервера и кластеров, которые расположены на нем.
Rmngr exe что это
PHP, Java, Delphi, 3D
Оптимизация скорости работы «1С:Підприємство». Процесс «1С:Підприємство» rmngr.exe грузит процессор
Один из серверов «1С:Підприємство», который я обслуживаю, очень странно себя вел. Загрузка процессора на машине с сервером «1С:Підприємство» почти всегда была 100%, даже когда на нем никто не работал. Базы хранились в MSSQL, их было относительно много, но реально людей, которые с ними работали — мало. Одновременно работало не больше 10-15-ти пользователей в очень вялом режиме.
Введение
Этот сервер привлек мое внимание сразу же, как только я стал с ним работать. Предыдущий администратор безрезультатно бился над производительностью, приобрел 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С:Підприємство» не рекомендует постоянно использовать такой режим работы, так как он является отладочным.
rmngr съел всю доступную память сервера (32 ГБ)
По монитору ресурсов процесс rmngr.exe
Завершено 32 ГБ // Private Bytes
Рабочий набор 5 ГБ // Working Set
Пиковый рабочий набор 22 ГБ // Peak Working Set
Согласно статьи: https://its.1c.ru/db/metod8dev#content:5815:hdoc
в этом случае нужно снимать дамп памяти и отправлять в 1С.
Файл дампа, я так понимаю, будет на 32 ГБ? И как его тогда отправлять?
Кто-нибудь пробовал?
Что ответили из 1С?
Я так понимаю, нет никаких средств посмотреть почему rmngr съел столько памяти?
Версия платформы 8.3.6.2449
Фоновое задание, которое долго исполнялось, может давать такой эффект на rmngr?
Почему-то файлы логов все пустые.
Почему-то эта настройка тех. журнала собирает логи только процессов w3wp и mmc.
Как настроить тех.журнал, чтобы он собирал логи по rmngr?
По всей видимости, в настройках тех.журнала надо еще какой-то пункт кроме утечек памяти включить.
(14) Регламентное задание запускает на выполнение несколько десятков тысяч строк кода по разным условиям. Если бы это была одна процедура, можно было бы проанализировать, а так нет.
(15) Я точно знаю из-за какого это регламентного задания, но мне от этого не легче (см. выше).
(16) Оно выполняется одно и в один поток. В это время никакие больше регламентные задания в базе не выполняются.
(17) К сожалению, не мой вариант. Это относится к 8.3.7, неизвестно есть ли этот баг в 8.3.6, да и фоновое задание только одно.
Попробовал поискать на багборде по ключевому слову rmngr. Ничего подходящего нет.
Всё же я думаю нужно как-то по-хитрому настроить сбор логов тех.журнала, чтобы отловить это.
Например, что по этой строке лога можно понять?
Ну вот, опять.
В системном журнале Windows:
При этом в логах технологического журнала есть только процессы w3wp.
Вот настройки тех.журнала:
(20) Да, писанный монстр по загрузке документов из внешней системы.
>возможно дробления
Так и сделал, разделил регламентное задание на 3 куска, указав параметр «завершать после» у первых 2-х кусков.
Посмотрим.
(22) Я думаю дело не в платформе, а в каком-то хитром коде. Только выяснить это не удается.
С памятью всё устаканилось, но после завершении сеанса регламентного задания сообщение «Аварийно завершился рабочий процесс фонового задания».