rmngr съел всю доступную память сервера (32 ГБ) #770100

По монитору ресурсов процесс rmngr.exe Согласно статьи: в этом случае нужно снимать дамп памяти и отправлять в 1С. Файл дампа, я так понимаю, будет на 32 ГБ? И как его тогда отправлять? Кто-нибудь пробовал? Что ответили из 1С? Я так понимаю, нет никаких средств посмотреть почему rmngr съел столько памяти? Версия платформы 8.3.6.2449

почему съел - или есть или нет. Как съел - можно, через технологический журнал. Есть материалы на итс и в сети

Причём тут эта тема? Там пишут про логи и загрузку процессора, а не память.

Есть готовые настройки для сбора тех.журнала именно для потребления памяти rmngr?

2 не знаю, есть?

"События LEAKS — события, связанные с утечкой памяти, которые могут быть вызваны ошибками в коде конфигурации. События MEM — события, связанные с увеличением объема памяти, занятой серверными процессами (ragent, rmngr, rphost). "

Фоновое задание, которое долго исполнялось, может давать такой эффект на rmngr?

Попробовал снять дамп с процесса, так и есть файл на over 30 ГБ. Это не вариант вообще. Только настраивать сбор логов.

Подскажите, это правильный файл logcfg.xml Почему-то файлы логов все пустые.

Опять тоже самое. Почему-то эта настройка тех. журнала собирает логи только процессов w3wp и mmc. Как настроить тех.журнал, чтобы он собирал логи по rmngr?

Как такое может быть, что регламентное задание завершается без ошибок, а потом через 40 минут сеанс этого регламентного задания завершается с ошибкой "На сервере недостаточно памяти для выполнения задания." ?

В очередной раз rmngr отожрал уже 36 ГБ. В логах по утечкам памяти ничего :( По всей видимости, в настройках тех.журнала надо еще какой-то пункт кроме утечек памяти включить...

Сам код анализировал?

Отключи все регламентные задания. Перезапусти службу агента. Потом запускай регламентные задания в порядке убывания вероятности причастности. Если они не причем, то дальше попробуй сделать тоже самое с пользователями.

С регламентными заданиями желательно диагностику эту проводить в нерабочее время, чтобы вход пользователей был заблокирован.

Фоновые задания все могут. И память съесть и и сервер приложений в ступор вогнать... В 1С с этим непрерывно борются Ели поискать  по слову "rmngr", можно найти еще аварийных завершений/зависаний в зависимости от ситуации. Я к тому, что неплохо было бы платформу обновить до последней какой-нибудь, чтобы выяснить из-за чего так, поведение платформы, код в рег. задании, или, на самом деле, физической памяти для ваших задач нужно просто больше.

Регламентное задание запускает на выполнение несколько десятков тысяч строк кода по разным условиям. Если бы это была одна процедура, можно было бы проанализировать, а так нет. Я точно знаю из-за какого это регламентного задания, но мне от этого не легче (см. выше). Оно выполняется одно и в один поток. В это время никакие больше регламентные задания в базе не выполняются. К сожалению, не мой вариант. Это относится к 8.3.7, неизвестно есть ли этот баг в 8.3.6, да и фоновое задание только одно. >физической памяти для ваших задач нужно просто больше Я понимаю, когда rphost много жрёт памяти -- это действительно что-то с кодом, т.к. именно в контексте этого процесса выполняется код. Но когда жрёт память rmngr -- становится непонятно. Попробовал поискать на багборде по ключевому слову rmngr. Ничего подходящего нет. Всё же я думаю нужно как-то по-хитрому настроить сбор логов тех.журнала, чтобы отловить это. Например, что по этой строке лога можно понять?

Ну вот, опять. В системном журнале Windows: При этом в логах технологического журнала есть только процессы w3wp. Вот настройки тех.журнала: Какие еще галки нужно поставить, чтобы начали писаться логи по процессам rmngr и rphost ?

это что за регламентное? глаза боятся, а руки копают. если это писанный монстр, то пришло время оптимизации и возможно дробления.

Да, писанный монстр по загрузке документов из внешней системы. >возможно дробления Так и сделал, разделил регламентное задание на 3 куска, указав параметр "завершать после" у первых 2-х кусков. Посмотрим.

а отчего так пухнуть-то может? прочитал данные. извлек нужные данные по базе. записал нужные данные. хрен ли здесь пухнуть? передовая платформа требует передовых мощностей?

Я думаю дело не в платформе, а в каком-то хитром коде. Только выяснить это не удается. С памятью всё устаканилось, но после завершении сеанса регламентного задания сообщение "Аварийно завершился рабочий процесс фонового задания".

ну как всегда побакланили, и нифига толку

как найти этот код: Смотрим код, выполняемый фоновым заданием. Определяем в нем границы логических блоков. Например, в начале алгоритма выполняется какой-то запрос, затем полученная выборка как-то обходится и для каждого элемента выполняются какие-то вычисления. Затем результат вычислений пишется обратно в базу (создаются/обновляются документы). Итого получаем 3 блока: выборка, вычисления, запись. Между ними добавляем в код что-то вроде ЗаписьЖурналаРегистрации с какими-то понятными комментами,которые легко будет потом найти в ЖР. После того,как очередное ФЗ свалилось, идём в ЖР и понимаем по комментариям, какой блок выполниться не смог. Делим его на более мелкие блоки, добавляем ЗаписьЖурналаРегистрации между ними и продолжаем локализацию бага таким образом. В конце концов уткнемся викакой-то бесконечный цикл, безвыходную рекурсию или тяжёлый запрос. Синим,радуемся,убираем отладочные комментарии.

мну - откатил релиз чуть вниз , выставил интервал по времени перезапуска больше (в консоли сервера 1С) - не знаю что именно из этого помогло - но работает

лучше call'ы смотреть с допустим > 1Gb

Самый простой пример: Виртуальная таблица остатки и обороты по регистратору кушает прилично памяти на сервере 1С

Это же временно. Память должна освобождаться при выходе из процедуры/функции, если ссылок не осталось. Проблема НЕ в том, чтобы определить где свалилось. Сейчас проблема такая, журнал регистрации: При этом в консоли регламентных заданий:

Пишешь запрос в 1С. Они тебе присылают ссылку на FTP, а так же логин и пароль.