Процес 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С не рекомендує використовувати такий режим роботи, так як він є налагоджувальний.
В черговий раз я переміг гальма 1С у вигляді 100% завантаження процесора сервісом rmngr.exe. З базами 1С ніколи не доводиться нудьгувати, постійно вирішуєш якісь питання і проблеми, які виникають найчастіше після оновлень. З настороженістю дивлюся на зростання споживання ресурсів процесами rphost.exe. Чуттям чую, що скоро доведеться вирішувати питання завантаження процесора саме ними.