rmngr.exe грузит процессор #761682

Всем доброго времени суток. Надеюсь получить полезный совет. В последние несколько дней заимел проблемы с сервером и, как следствие, проблемы на тонких клиентах, которые работают очень медленно. Нагрузка на серверный процессор возросла до 100% и держится непрерывно. Диспетчер задач указывает, что основная проблема в rmngr.exe, который вкупе с процессами rphost.exe полностью загружает процессор. Анализ mngr.exe с помощью Process Monitor от Windows Sysinternals показал, что идет непрерывный доступ к C:Program Files (x86)1cv8srvinfo eg_1541xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx1Cv8Log1Cv8.lgd, где "xxx" — абсолютно разные каталоги. Если бы это был доступ к логам какой-то определенной базы, то можно было бы выявить закономерность, но доступ идет к разным и в основном это операции чтения. Процесс rmng.exe это менеджер сервера и я не могу понять, почему он стал настолько активным. Раньше все работало гладко. Конфигурация: Windows Server 2008 R2 + MS SQL Server 2008 R2 + 1C 8.3.7.1776. На сервере находятся 18 баз данных: стандартные БП, ЗУП и парочка самописных. Отключение самописных баз не повлияло и нагрузка на процессор осталась. Доступ к базам данных ведется с рабочих станций доменов через локальную сеть и VPN, а также через сервер терминалов.

Скорее всего висят спящие сеансы в очень большом количестве

по умолчанию 1С усыпляет сеансы на сутки, иногда она начинает сходить с ума и начинает каждую секунду порождать по 2-3 спящих сеанса. Т.е. нужно в консоли посмотреть так ли это. И если это так то в параметрах базы уменьшить время жизни таких сеансов с 24 часов хотя бы до минут 10

переходите на старый формат журнала регистрации.

Aleksey, системный планировщик каждую ночь перезапускает все службы, связанные с сервером 1C и MS SQL. По идее, все должно убиваться.

+ к Как вернуть базу на старый формат журнала регистрации? Ответ - При остановленном сервере приложений -- найти в папке базы в кластере (...srvinfo eg_<PortNo><GUID>) папку журнала регистрации (1Cv8Log); -- из папки 1Cv8Log удалить все файлы (или переместить/переименовать папку); -- в папке 1Cv8Log создать пустой файл 1Cv8.lgf;

Ты будешь смеяться но ни перезагрузка компьютера, ни переустановка сервера 1С не убивает эти процессы. Походу он куда то в блокнотик себе пишет и при восстановлении сервера автоматом восстанавливает и эти сеансы

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

Aleksey, я не вижу "левых" сеансов.

Ошибка с неконтролирумым ростом нагрузки на процесс при использовании нового формата журнала регистрации  обсасывалась на партнерском форуме. Пост взят оттуда. 1С обещала проблему устранить, но сроки не озвучивала. В 8.3.7 проблема пока есть. Конкретных причин возникновения проблемы не знаю. У нас журнал работает нормально (тьфу-тьфу-тьфу).

Я замечал что ппц начинается если усиленно в журнале чтото искать и делать отборы, причём в динамическом режиме

Dmitrii, можешь расписать алгоритм моих действий поподробнее? Правильно ли я понял? 1. Остановить 1С сервер. 2. Переименовать каталог 1Cv8Log в 1Cv8Log.bak для каждого GUID. 3. Для каждого GUID создать новый каталог 1Cv8Log и создать внутри файл 1Cv8.lgf.

Можно и так, чтобы сохранить имеющиеся логи (п.2) Недостаток данного метода в том, что ведение журнала начнется с нуля. Все предыдущие логи останутся в папках 1Cv8Log.bak Но другого способа возвращения на журнал старого формата увы нет.

Меня сейчас логи мало волнуют, больше интересует стабильность сервера, тем более, под конец года. Если ты говоришь, что у тебя нет проблем с журналами, то посмотри, пожалуйста, сколько весят твои lgd-файлы.

Еще не совсем понятно, почему появились эти проблемы. Релиз был установлен 12 декабря и после установки сервер работал быстро, но примерно три дня назад начались проблемы. Размер журналов меня мало интересовал раньше. Сейчас глянул — 25 ГБ на все 18 баз данных. Базы мигрировали с файловой версии на MS SQL примерно полгода назад.

Garikk, этим можно было бы объяснить причины, но они явно в другом, потому что нагрузка на процессор достигает 100% даже ночью, когда точно никто не работает.

Лог основной рабочей базы - 23Гб. Сама база ~50Гб. БП 3.0. За период с марта по настоящее время. Лог не сокращали и не выгружали.

Ошибка журнала плавающая. Если я правильно понял, то часто возникает при обменах данными (РИБ) и интенсивной работе с журналом по типу .

Хм, спасибо. Сегодня в 13:00, когда все юзвери уйдут обедать, я постараюсь вернуться к старой системе журналирования. О результатах отпишусь позже.

Кстати вместо сохранения логов в папки 1Cv8Log.bak лучше воспользоваться типовым методом СкопироватьЖурналРегистрации с указанием имени выходного файла. Получите файл, который потом сможете смотреть в 1С в конфигураторе или в пользовательском режиме.

+ к Только следует учесть, что это может занять очень много времени.

Такой метод займет много времени, если я буду ковырять все 18 баз данных. Если приспичит, то я потом перекину логи на другой аналогичный сервер с такой же конфигурацией, где пока нет таких проблем.

Думаю, будет проще и быстрее остановить сервер, пробежаться руками по каждому GUID через проводник и в каждый GUID вставить заранее заготовленный 1Cv8Log с пустым 1Cv8.lgf.

Отписываюсь, как и обещал. Первые 20 минут работы сервера после проделанных манипуляций. Сервер пишет журналы в .lgf и автоматический созданные .lgp-файлы. Первый запуск баз данных после перезапуска служб был очень долгим, однако работа вполне быстрая. Процесс rmngr.exe загружает процессор на 1-5%, однако я заметил, что процессы rphost.exe начали потреблять больше, но сервер все равно не загружается на 100%. Нагрузка не постоянная, а скачкообразная, в среднем около 80%. Оставляю этот комментарий на тот случай, если вдруг кто-то столкнется с подобной проблемой. Возможно, через Яндекс или Google он сможет наткнуться на эту тему. Всем спасибо.

У меня проблема точно такая же. за неделю логи достигают 28 Гб и грузят проц на 60-70%. Помогает только чистка логов. Попробовал заменить логи на старый формат, как написано тут. Запустил сервер, в базы заходит, но при попытке посмотреть любой отчет, базы зависали и не реагировали никак. поменял логи обратно - все работает. что я делаю не так?

>> при попытке посмотреть любой отчет, базы зависали Речь об отчетах по журналу регистрации или отчетах вообще (любых, по регистам и пр.).

>> за неделю логи достигают 28 Гб ... Помогает только чистка логов Если для вас логи не так сильно важны, то может имеет смысл попробовать настроить журнал регистрации, чтобы вообще не регистрировать никакие события или только ошибки? Именно попробовать, чтобы убедиться, что проблема именно в этом. Еще можно попробовать в свойствах рабочего сервера кластера установить галку "Менеджер под каждый сервис". Под сервис журналов регистрации будет выделен отдельный менеджер rmngr.exe. Понаблюдать за ним.

отчет любой. оборотно-сальдовая по счетам например

в общем фиг знает, сегодня подложил туже самую папку со старым форматом лога, что и до этого - все заработало. Фиг знает, что с ним было до этого. спасибо, буду наблюдать