После очередного обновления конфигурации начали падать rphost. Падают каждые 15 минут.
В ТЖ
37:40.832000-0,EXCP,0,process=rphost,p:processName=RHostRoot,OSThread=6360,OSException=rphost_8.3.13.1644_6b2b7ca0_20191010133740_8684 enabled external
37:40.832001-0,EXCPCNTX,0,ClientComputerName=,ServerComputerName=,UserName=,ConnectString=
37:40.832003-0,EXCP,0,process=rphost,p:processName=RHostRoot,OSThread=6360,DumpError=DirBin property is empty
37:40.894000-0,EXCP,0,process=rphost,p:processName=RHostRoot,OSThread=6360,DumpError=Created dump file: G:\ТЖ\Dumps\rphost_8.3.13.1644_6b2b7ca0_20191010133740_8684.mdmp
Падают только процессы обслуживающие обновленные базы и только в рабочее время.
Включал полное протоколирование в ТЖ, каких-то общих событий предшествующих падению нет.
Обновление платформы ничего не меняет. Подскажите, в какую сторону копать?
(1) Копать в сторону последнего обновления, анализировать, что меняли. Вполне вероятно, что происходит переполнение стека в результате бесконечной рекурсии в одном из регламентных заданий.
(2) Регламентные задания ни при чем. Падает только в рабочее время. Анализировать код обновления в надежде найти ошибку приводящую к падению нереально. Там только в структуре метаданных изменений штук 50, а модули если просматривать, то можно до нового года не управиться. Переполнение стека вроде должно быть видно в ТЖ, но там ничего подозрительного.
(3) Так же не понятно: конфигурация - какое-то типовое решение или самописное?
Если типовое и для управляемого приложения, то там отчеты и прочие "долгие" операции работают через фоновые задания.
(7) Доработанное типовое. Если бы падало из-за конкретной операции - это четко было бы видно в ТЖ. Но в ТЖ предшествующие падению события всегда разные.
(1) уберите настройки ограничения по превышению памяти в консоли администрирования 1С (если стоят у кластера и у рабочего сервера) + ПРОВЕРЬТЕ завершились ли все обработки обновления (Администрирование - Обслуживание - Результаты обновления)
(1) тоже боролись с вылетом службы, в итоге написали на линию поддержки 1С, они предложили обновить компоненту печати штрихкода, взяв её из БПО, так как новый релиз с обновленной компонентой не скоро. Обновили, проблема ушла. Валилась так же, исключительно в рабочее время. Т.е. получается просто пользователи печатали документы и это чудо падало.
Попробуй для начала систему про сканировать на битые системные файлы: в cmd прописать SFC /Scannow
Попробуй отключить журналы регистрации или перенести их в другое место
По крайней мере у меня это решило проблемы (после обновления на новую платформу), когда 1с зависала каждые 10 минут после начала работы и оснастка mmc падала замервто
У меня такое было, когда с лицензией были проблемы. Посмотрите как установлена лицензия. Ошибки с лицензией сбойной иногда не протоколируются, потому что подразумевается что вы взломали 1С.
Можно журнал Windows на сбои rphost настроить, там можно увидеть статусы изменения процесса. И, возможно, ошибки при работе. Приготовьтесь замедлить работу rphost, настраивать журнал лучше ночью.
Дополнение к ответу: платформа 8.3.13.1926 (в процессе поиска ошибки поменяли несколько релизов), конфигурация Бухгалтерия 3.0.72.70 (измененная). Падения начали наблюдаться после обновления 2-3 недели назад, проблема решилась недавно с помощью указанного ответа 1С.
Добрый день, был еще случай когда в свойствах кластера 1с был указан допустимый объем памяти в тысячу раз меньший чем планировался. Админ просто не обратил внимание на единицу измерения KB, привык что везде используются Мегабайты. Как итог несколько дней не могли понять по какой причине раз в несколько минут происходили жесткие фризы и иногда с выбросов всех из программы.
Добрый день. А компонента печати штрихкодов обновляется через конфигуратор путем замены макета или есть еще какой-либо путь обновления компоненты ?
Вышел релиз бухгалтерии с исправленной компонентой ?
Эти вылеты касаются только бухгалтерских программ или еще торговли с зарплатой ?