Приветствую коллеги! Периодически возникает ситуация, когда при формировании отчетов в фоновых заданиях разворачиваются следующие события:
В ТЖ возникает событие func=killClient с признаком ADMIN на фоновое задание, которое формирует отчет пользователю. Он в свою очередь получает ошибку "Cannot continue the execution because the session is in the kill state". Также есть событие ""
В SQL профайлере и журнале событий сервера отчетливо видно, что 1С шлет команду "KILL 56" (или любой другой номер).
В какой-то момент остальные пользователи начинают получать ошибки "The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION" или "cannot find the object "#tt1"". Оно и понятно, связь с сервером SQL разорвана и 1С этого не понимает.
Всех пользователей, у которых возникают такие ошибки объединяет всегда один общий рабочий процесс. Далее менеджер фоновых заданий продолжает убивать соединения на рабочем процессе остальных пользователей. Вернее он не дает выполнять никаких запросов, пресекая их. Пользователи выходят, снова заходят и их уже в базу не пускает, все те же самые ошибки. 1С пытается их повесить на тот же самый проблемный рабочий процесс. Пока вручную не прибьешь рабочий процесс через диспетчер задач - ничего не помогает.
Все глаза проглядел сканируя ТЖ на предмет ответов на вопрос - почему. Никаких исключений связанных с нехваткой памяти я не нашел. На основании каких критериев 1С может принимать решение об обрывах соединений с SQL сервером и при этом не трогать сам rphost?
В ТЖ возникает событие func=killClient с признаком ADMIN на фоновое задание, которое формирует отчет пользователю. Он в свою очередь получает ошибку "Cannot continue the execution because the session is in the kill state". Также есть событие ""
В SQL профайлере и журнале событий сервера отчетливо видно, что 1С шлет команду "KILL 56" (или любой другой номер).
В какой-то момент остальные пользователи начинают получать ошибки "The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION" или "cannot find the object "#tt1"". Оно и понятно, связь с сервером SQL разорвана и 1С этого не понимает.
Всех пользователей, у которых возникают такие ошибки объединяет всегда один общий рабочий процесс. Далее менеджер фоновых заданий продолжает убивать соединения на рабочем процессе остальных пользователей. Вернее он не дает выполнять никаких запросов, пресекая их. Пользователи выходят, снова заходят и их уже в базу не пускает, все те же самые ошибки. 1С пытается их повесить на тот же самый проблемный рабочий процесс. Пока вручную не прибьешь рабочий процесс через диспетчер задач - ничего не помогает.
Все глаза проглядел сканируя ТЖ на предмет ответов на вопрос - почему. Никаких исключений связанных с нехваткой памяти я не нашел. На основании каких критериев 1С может принимать решение об обрывах соединений с SQL сервером и при этом не трогать сам rphost?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) Как раз обновили недавно, в надежде, что эта проблема уйдет. Была платформа 8.3.7.2027, поставили 8.3.13.1690. Переустановили полностью серверную ОС на гипервизоре, перешли на MSSQL 2014.
С дисками вроде бы все нормально. Во всяком случае сервер "холодный", ничего не загружено. При этом ошибка может проявляться как ночью на каком-нибудь регламентном задании, когда никого нет в базе вообще, так и на 3 пользователях, которые кроме как отчеты ничего не формируют.
Кластер настроен практически по-умолчанию. 1 процесс на 1 базу, 50 соединений на процесс. 500Гб ОЗУ, 100Гб обычно съедает SQL сервер, 50-90Гб общая сумма потребления памяти рабочими процессами при 400 пользователях. При 3х пользователях около 10Гб. IOPSов хватает, очередей к дискам нет. Ядра не загружены. Планы обслуживания работают, дефрагментации индексов, реструктуризации при необходимости, чистка процедурного кэша. DBCC CHECKDB никаких ошибок не выявляет.
С дисками вроде бы все нормально. Во всяком случае сервер "холодный", ничего не загружено. При этом ошибка может проявляться как ночью на каком-нибудь регламентном задании, когда никого нет в базе вообще, так и на 3 пользователях, которые кроме как отчеты ничего не формируют.
Кластер настроен практически по-умолчанию. 1 процесс на 1 базу, 50 соединений на процесс. 500Гб ОЗУ, 100Гб обычно съедает SQL сервер, 50-90Гб общая сумма потребления памяти рабочими процессами при 400 пользователях. При 3х пользователях около 10Гб. IOPSов хватает, очередей к дискам нет. Ядра не загружены. Планы обслуживания работают, дефрагментации индексов, реструктуризации при необходимости, чистка процедурного кэша. DBCC CHECKDB никаких ошибок не выявляет.
(4) 64 бит. Я же говорю настройки кластера стоят по умолчанию. Там нет заданных лимитов по памяти и принудительного завершения проблемных процессов (в моем случае процесс и не убивается, убиваются соединения). Размер базы 250Гб. Режим совместимости 8.3.6. А что может быть с темп дб? Ему не все равно располагается он на диске C или D? 99% времени кластер все устраивает, а в оставшийся 1% он вдруг решает, что у него не там темп дб лежит или как?
Есть предположение, что на это влияет параметр "Безопасный расход памяти за один вызов". Если он установлен по умолчанию, то значение определяется как 5% от "Максимального объема памяти рабочих процессов". Если же и он по умолчанию, то его значение определяется как 80% от общего объема ОЗУ.
Если на сервере 500Гб ОЗУ, то получается следующее: 500 * 0,8 = 400 * 0,05 = 20Гб. Т.е. при утечке памяти на рабочем процессе, если его память дойдет до 20Гб, то теми самыми "неудачником" может оказаться любой, кто попытается запустить фоновое задание, которое хоть на 1 байт попробует превысить допустимый размер.
Видимо надо параллельно делать настройку "Объем памяти рабочих процессов, до которого сервер считается производительным", чтобы этот рабочий процесс не принимал больше никаких соединений.
Это все теория, надо проверять.
Если на сервере 500Гб ОЗУ, то получается следующее: 500 * 0,8 = 400 * 0,05 = 20Гб. Т.е. при утечке памяти на рабочем процессе, если его память дойдет до 20Гб, то теми самыми "неудачником" может оказаться любой, кто попытается запустить фоновое задание, которое хоть на 1 байт попробует превысить допустимый размер.
Видимо надо параллельно делать настройку "Объем памяти рабочих процессов, до которого сервер считается производительным", чтобы этот рабочий процесс не принимал больше никаких соединений.
Это все теория, надо проверять.
(8) Проверил, ни того ни другого события нет в журнале.
Второй день идет, пока проблем нет. Но и проблема всплывает эпизодически 1-2 дня в месяц подряд.
(10) На других серверах тоже пришлось отказаться от такой настройки, потому, что там 27 баз и всего 3 программиста-разработчика, которые на них тестируют. А ресурсов ограничено. Если такую настройку сделать, то никакой оперативной памяти не хватит.
Судя по журналу, 8 раз сегодня рабочие процессы завершались и новые запускались. Но жалоб не было. Стало быть пока 1С удачно перекидывает людей с проблемных рабочих процессов.
Второй день идет, пока проблем нет. Но и проблема всплывает эпизодически 1-2 дня в месяц подряд.
(10) На других серверах тоже пришлось отказаться от такой настройки, потому, что там 27 баз и всего 3 программиста-разработчика, которые на них тестируют. А ресурсов ограничено. Если такую настройку сделать, то никакой оперативной памяти не хватит.
Судя по журналу, 8 раз сегодня рабочие процессы завершались и новые запускались. Но жалоб не было. Стало быть пока 1С удачно перекидывает людей с проблемных рабочих процессов.
В общем что-то не клеится с теорией. Сделал все необходимые настройки. Прописал допустимый объем памяти одного процесса чуть меньше порога в 20Гб. Сделал настройку перезапуска при превышении. Пока проблем нет. 1С перекинул соединения на новый процесс и прибил старый. Пользователи вроде бы не заметили. Есть подозрения, что все-таки какой-то неявный допустимый объем памяти для рабочего процесса у 1С есть, даже если настройка стоит 0. Не могу вспомнить за все это время, чтобы один рабочий процесс был хотя бы 30Гб
События гляну, но ничего подобного ни разу пока не видел.
События гляну, но ничего подобного ни разу пока не видел.
Включил поимку событий ATTN и в паре с PROC они дают наиболее полную картину происходящего.
"Process has generated too big amount of exceptions" - вот это событие означает, что в настройках кластера задано не нулевое "Допустимое отклонение количества ошибок сервера". Вместе с настройкой "Принудительно завершать проблемные процессы" они приводят к тому, что процесс, который по статистике сервера 1С начал генерировать большее количество исключений, в событии CALL, чем обычно (процент отклонения) - принудительно уничтожается.
Похоже, что в отличие от события "Process excess memory limit" (это я задал допустимый объем потребления оперативной памяти одним процессом), 1С не пытается перекинуть соединения на другой рабочий процесс, а просто его завершает без объявления войны.
Вот события агента сервера, где процесс запускается:
Вот события PROC самого процесса 14360:
Обратите внимание, что тут нет события "Process terminated" и на тайминги:
42:07.692068-1 - агент порождает процесс 14360
42:07.817000-0 - процесс подает первый голос...
42:09.817005-0 - пользователь пытается покормить малыша несъедобным, на что малыш начинает плакать
42:12.301043-0 - агент принимает решение убить дитя, так как тот слишком много плачет...
42:17.317050 - бездыханное тело (abandoned процесса) остается на месте преступления до момента сокрытия улик
Т.е. хватило всего 10 секунд на все про все.
Когда я начал разбираться какие же именно исключения привели к такому печальному последствию, то я нашел следующее:
У одного из пользователей в настройках прописано имя "basa" вместо "baza". При попытке подключения к процессу возникло одно единственное исключение. Если оно обвалило процесс, то это очень странное поведение... Больше никаких исключений у процесса не было. О каком отклонении тут может идти речь не понятно.
Пока выставил "Допустимое отклонение количества ошибок сервера" в ноль. Наблюдаю дальше.
03:35.066051-0,ATTN,13,process=ragent,OSThread=7532,Descr=Process excess memory limit,agentURL=tcp://SERVER-1:1540,procURL=tcp://SERVER-1:1566,Pid=15608,Name=rphost,MemSize=10563196,MaxMemSize=10485760
03:40.081059-0,ATTN,13,process=ragent,OSThread=7532,Descr=Process excess memory limit,agentURL=tcp://SERVER-1:1540,procURL=tcp://SERVER-1:1566,Pid=15608,Name=rphost,MemSize=10563196,MaxMemSize=10485760
42:12.301043-0,ATTN,14,process=ragent,OSThread=7532,Descr=Process has generated too big amount of exceptions,agentURL=tcp://SERVER-1:1540,procURL=tcp://SERVER-1:1572,Pid=14360,Name=rphost,CurExceptions=1,AvgExceptions=7.692307712009118e-2
42:12.301044-0,ATTN,14,process=ragent,OSThread=7532,Descr=Process will be killed,agentURL=tcp://SERVER-1:1540,procURL=tcp://SERVER-1:1572,Pid=14360,Name=rphost,logOnly=0
42:17.317050-0,ATTN,14,process=ragent,OSThread=7532,Descr=Process is abandoned,agentURL=tcp://SERVER-1:1540,procURL=tcp://SERVER-1:1572,Pid=14360,Name=rphost
42:42.379069-0,ATTN,14,process=ragent,OSThread=7532,Descr=Process is abandoned,agentURL=tcp://SERVER-1:1540,procURL=tcp://SERVER-1:1572,Pid=12304,Name=rphost
"Process has generated too big amount of exceptions" - вот это событие означает, что в настройках кластера задано не нулевое "Допустимое отклонение количества ошибок сервера". Вместе с настройкой "Принудительно завершать проблемные процессы" они приводят к тому, что процесс, который по статистике сервера 1С начал генерировать большее количество исключений, в событии CALL, чем обычно (процент отклонения) - принудительно уничтожается.
Похоже, что в отличие от события "Process excess memory limit" (это я задал допустимый объем потребления оперативной памяти одним процессом), 1С не пытается перекинуть соединения на другой рабочий процесс, а просто его завершает без объявления войны.
Вот события агента сервера, где процесс запускается:
42:07.692068-1,PROC,0,process=ragent,OSThread=6952,Txt='Run process. Prog=D:\Program Files\1cv8\8.3.13.1690\bin\rphost.exe, Command=("D:\Program Files\1cv8\8.3.13.1690\bin\rphost.exe" -range 1560:1591 -reghost SERVER-1 -regport 1541 -pid dba20a33-774f-4a3f-92c7-9f9ef7206087 -fromsrvc), success, pid=14360'
Вот события PROC самого процесса 14360:
42:07.817000-0,PROC,1,process=rphost,OSThread=5116,Err=0,Txt=1C:Enterprise 8.3 (x86-64) (8.3.13.1690) Working Process started. Ctrl+C to exit.
Обратите внимание, что тут нет события "Process terminated" и на тайминги:
42:07.692068-1 - агент порождает процесс 14360
42:07.817000-0 - процесс подает первый голос...
42:09.817005-0 - пользователь пытается покормить малыша несъедобным, на что малыш начинает плакать
42:12.301043-0 - агент принимает решение убить дитя, так как тот слишком много плачет...
42:17.317050 - бездыханное тело (abandoned процесса) остается на месте преступления до момента сокрытия улик
Т.е. хватило всего 10 секунд на все про все.
Когда я начал разбираться какие же именно исключения привели к такому печальному последствию, то я нашел следующее:
42:09.817005-0,EXCP,3,process=rphost,p:processName=basa,OSThread=9052,t:clientID=5,t:applicationName=1CV8C,t:computerName=PC-1,Exception=580392e6-ba49-4280-ac67-fcd6f2180121,Descr='src\VResourceInfoBaseImpl.cpp(1073):
580392e6-ba49-4280-ac67-fcd6f2180121: Неспецифицированная ошибка работы с ресурсом
Ошибка при выполнении запроса POST к ресурсу /e1cib/login:
a01f465c-ed70-442e-ada5-847668d7a41c: Информационная база не обнаружена'
У одного из пользователей в настройках прописано имя "basa" вместо "baza". При попытке подключения к процессу возникло одно единственное исключение. Если оно обвалило процесс, то это очень странное поведение... Больше никаких исключений у процесса не было. О каком отклонении тут может идти речь не понятно.
Пока выставил "Допустимое отклонение количества ошибок сервера" в ноль. Наблюдаю дальше.
Итак падения не прекратились. На этот раз причина уже другая.
По ТЖ увидел событие PROC с убийством процесса ночью, когда никого не было в базе. В поисках причин открыл журнал SQL сервера и увидел, что в это же время зарегистрировалось событие:
Далее в событии CONN увидел, что у процесса был увеличенный ответ на пинги. По умолчанию рабочие процессы пингуются раз в секунду и ждут 5 секунд ответа, чтобы понять жив он или нет. Если после трех попыток ответ так и не получен, то 1С убивает такой процесс. Это и произошло.
Нашел другие падения ранее по журналу, соотнес время с логами на SQL сервере.
Оставалось разобраться, что означает этот I/O frozen. А это следствие снятия бэкапов средствами VSS (Volume Shadow Copy Service).
В момент снятия бэкапа методом SNAPSHOT, служба VSS обращается к сервису SQLWriter, чтобы корректно снять копии файлов баз данных на диске.
Задержка между отключением и включением ввода/вывода составляет 20 секунд (Microsoft дает сделать эту задержку не более 60 секунд, в противном случае бэкап завершится неудачей). Этого времени хватает, чтобы подвесить пользователей в 1С и принять решение убить молчащие процессы, т.к. 5*3 =15 сек., а это меньше.
В этом случае 1С также не перекидывает соединения на другие процессы, даже не пытается помечать процесс как нерабочий (disabled). Возможно самому рабочему процессу в отсутствии попыток его пинговать нужно принимать решение о том, что за ним скоро "придут" и что-то делать с существующими соединениями до того как его прибьют.
Выставил параметр в командной строке запуска агента сервера 1С -pingTimeout 25000 (25*3=75, должно хватить, если в худшем случае задержка дойдет до 60 секунд).
Наблюдаем дальше. Но похоже, что уже пора разносить сервер 1С и SQL сервер на разные машины.
По ТЖ увидел событие PROC с убийством процесса ночью, когда никого не было в базе. В поисках причин открыл журнал SQL сервера и увидел, что в это же время зарегистрировалось событие:
I/O is frozen on Database (DatabaseName).No User action is required. However, if I/O is not resumed promptly, you could cancel the backup.Далее в событии CONN увидел, что у процесса был увеличенный ответ на пинги. По умолчанию рабочие процессы пингуются раз в секунду и ждут 5 секунд ответа, чтобы понять жив он или нет. Если после трех попыток ответ так и не получен, то 1С убивает такой процесс. Это и произошло.
Нашел другие падения ранее по журналу, соотнес время с логами на SQL сервере.
Оставалось разобраться, что означает этот I/O frozen. А это следствие снятия бэкапов средствами VSS (Volume Shadow Copy Service).
В момент снятия бэкапа методом SNAPSHOT, служба VSS обращается к сервису SQLWriter, чтобы корректно снять копии файлов баз данных на диске.
Задержка между отключением и включением ввода/вывода составляет 20 секунд (Microsoft дает сделать эту задержку не более 60 секунд, в противном случае бэкап завершится неудачей). Этого времени хватает, чтобы подвесить пользователей в 1С и принять решение убить молчащие процессы, т.к. 5*3 =15 сек., а это меньше.
В этом случае 1С также не перекидывает соединения на другие процессы, даже не пытается помечать процесс как нерабочий (disabled). Возможно самому рабочему процессу в отсутствии попыток его пинговать нужно принимать решение о том, что за ним скоро "придут" и что-то делать с существующими соединениями до того как его прибьют.
Выставил параметр в командной строке запуска агента сервера 1С -pingTimeout 25000 (25*3=75, должно хватить, если в худшем случае задержка дойдет до 60 секунд).
Наблюдаем дальше. Но похоже, что уже пора разносить сервер 1С и SQL сервер на разные машины.
(14) Итак отписываюсь. Помогло только в случае с рабочими процессами. Но внезапно я нарвался на похожую проблему, источник похоже все тот же - создание бэкапов.
В воскресное утро, когда никого еще не было на работе, я решил перезапустить сервер 1С. Все прошло без проблем. Проходит 1 час и меня выкидывает с разрывом соединения. Ринулся смотреть ТЖ, а там такое:
Ни в каких событиях CONN нет информации о том, что менеджер кластера пинговался или как-то еще опрашивался.
Стал смотреть логи сервера и увидел такое:
The description for Event ID 129 from source storvsc cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer
Это происходило ровно в момент создания бэкапа лога транзакций.
Хуже того - это событие зарегистрировалось одновременно на двух разных виртуальных машинах (Hyper-V). Админы молчат. Что делать дальше - я не знаю, так как у 1С нет настроек, которые бы позволили увеличить время ожидания ответа от менеджера кластера (rmngr), а не от рабочего процесса...(rphost). Остальной софт (SQL сервер и т.д.) при этом ведет себя стабильно и не падает. Почему в 1С считают увеличением стабильности убийство собственных процессов по любому поводу - непонятно.
В воскресное утро, когда никого еще не было на работе, я решил перезапустить сервер 1С. Все прошло без проблем. Проходит 1 час и меня выкидывает с разрывом соединения. Ринулся смотреть ТЖ, а там такое:
55:47.896006-0,ATTN,2,process=ragent,OSThread=8456,Descr=Main manager not respond,agentURL=tcp://SERVER-1:1540,procURL=tcp://SERVER-1:1541,Pid=8928,Name=rmngr
55:47.896007-0,ATTN,2,process=ragent,OSThread=8456,Descr=Process will be killed,agentURL=tcp://SERVER-1:1540,procURL=tcp://SERVER-1:1541,Pid=8928,Name=rmngr,logOnly=0
55:48.958015-0,ATTN,3,process=ragent,OSThread=8456,Descr=Process is abandoned,agentURL=tcp://SERVER-1:1540,procURL=tcp://SERVER-1:1567,Pid=15072,Name=rphost
55:48.958016-0,ATTN,3,process=ragent,OSThread=8456,Descr=Process is abandoned,agentURL=tcp://SERVER-1:1540,procURL=tcp://SERVER-1:1541,Pid=8928,Name=rmngr
55:47.896007-0,ATTN,2,process=ragent,OSThread=8456,Descr=Process will be killed,agentURL=tcp://SERVER-1:1540,procURL=tcp://SERVER-1:1541,Pid=8928,Name=rmngr,logOnly=0
55:48.958015-0,ATTN,3,process=ragent,OSThread=8456,Descr=Process is abandoned,agentURL=tcp://SERVER-1:1540,procURL=tcp://SERVER-1:1567,Pid=15072,Name=rphost
55:48.958016-0,ATTN,3,process=ragent,OSThread=8456,Descr=Process is abandoned,agentURL=tcp://SERVER-1:1540,procURL=tcp://SERVER-1:1541,Pid=8928,Name=rmngr
Ни в каких событиях CONN нет информации о том, что менеджер кластера пинговался или как-то еще опрашивался.
Стал смотреть логи сервера и увидел такое:
The description for Event ID 129 from source storvsc cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer
Это происходило ровно в момент создания бэкапа лога транзакций.
Хуже того - это событие зарегистрировалось одновременно на двух разных виртуальных машинах (Hyper-V). Админы молчат. Что делать дальше - я не знаю, так как у 1С нет настроек, которые бы позволили увеличить время ожидания ответа от менеджера кластера (rmngr), а не от рабочего процесса...(rphost). Остальной софт (SQL сервер и т.д.) при этом ведет себя стабильно и не падает. Почему в 1С считают увеличением стабильности убийство собственных процессов по любому поводу - непонятно.
(19) Хмм, действительно. В этом случае, 1С не убивает rmngr.... после 11-ой безуспешной попытки запуска нового rmngr'a ragentом я галку вернул обратно.
Слишком уж он быстро начинает считать процесс проблемным.
И это, кстати, не спасает рабочие процессы, вслед за зависшим менеджером они все-равно убиваются:
Слишком уж он быстро начинает считать процесс проблемным.
И это, кстати, не спасает рабочие процессы, вслед за зависшим менеджером они все-равно убиваются:
41:29.427003-0,PROC,1,process=rphost,OSThread=5252,Err=0,Txt=1C:Enterprise 8.3 (x86-64) (8.3.13.1690) Working Process (debug) started. Ctrl+C to exit.
54:51.929000-0,PROC,0,process=rphost,OSThread=5984,Txt='Process terminated.
Stopped on error (root)'
54:51.929001-0,PROC,0,process=rphost,OSThread=1680,Txt='Process terminated.
Stopped on error (root)'
55:04.207000-0,PROC,1,process=rphost,OSThread=5252,Err=0,Txt=1C:Enterprise 8.3 (x86-64) (8.3.13.1690) Working Process (debug) finished.
ПоказатьПрикрепленные файлы:
(20) У вас sql на одном и том же железе что и сервер 1с, надо разносить.
Просто рмнгр то почему недоступным становится? Диски ложатся во время бэкапа логов или что?
Ну либо разносить на разные диски как минимум.
С точки зрения кластера 1с вроде всё логично, процесс не отвечает - убить.
Просто рмнгр то почему недоступным становится? Диски ложатся во время бэкапа логов или что?
Ну либо разносить на разные диски как минимум.
С точки зрения кластера 1с вроде всё логично, процесс не отвечает - убить.
(21) Да, на одном. Если разносить, то пропадет такая штука как Shared Memory.
Логично да не совсем. За менеджером кластера тянутся rphostы с пользователями. Думаю, что для менеджера кластера необходимо вводить настройку подобную pingTimeout, а rphostы "научить жить " без менеджера кластера до тех пор, пока не объявится приемный родитель в виде нового менеджера.
Логично да не совсем. За менеджером кластера тянутся rphostы с пользователями. Думаю, что для менеджера кластера необходимо вводить настройку подобную pingTimeout, а rphostы "научить жить " без менеджера кластера до тех пор, пока не объявится приемный родитель в виде нового менеджера.
Если кому интересно, вы можете провести маленький эксперимент. Настройте ТЖ на ловлю событий PROC и ATTN.
logcfg.xml
Затем перейдите в монитор ресурсов (windows) на сервере, где работает 1С и найдите там процесс rmngr. Щелкните правой кнопкой мышки и выберете "Приостановить процесс" (Suspend Process). Затем наблюдайте за тем как 1С начинает плодить менеджеров кластеров и убивать до тех пор пока не убьет тот процесс, который мы приостановили и не заменит его другим менеджером кластера.
А затем смотрим как это убивает еще и рабочие процессы:
"Stopped by console" - никакой консолью я не пользовался, 1С сама приняла решение завершить процесс.
logcfg.xml
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="D:\TechLog1C" history="24">
<event>
<eq property="Name" value="ATTN"/>
</event>
<event>
<eq property="Name" value="PROC"/>
</event>
<property name="All"/>
</log>
</config>
ПоказатьЗатем перейдите в монитор ресурсов (windows) на сервере, где работает 1С и найдите там процесс rmngr. Щелкните правой кнопкой мышки и выберете "Приостановить процесс" (Suspend Process). Затем наблюдайте за тем как 1С начинает плодить менеджеров кластеров и убивать до тех пор пока не убьет тот процесс, который мы приостановили и не заменит его другим менеджером кластера.
А затем смотрим как это убивает еще и рабочие процессы:
29:59.122000-30995,PROC,0,process=ragent,OSThread=4172,Txt='Run process. Prog=C:\Program Files\1cv8\8.3.13.1690\bin\rmngr.exe, Command=("C:\Program Files\1cv8\8.3.13.1690\bin\rmngr.exe" -port 1541 -host SERVER-1PC -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo\\" -debug -tcp -fromsrvc -clstid 30364321-ea18-43e0-ab2a-012cc2dd1d87), success, pid=10120'
30:00.932008-0,ATTN,2,process=ragent,OSThread=4168,Descr=Main manager not respond,agentURL=tcp://SERVER-1PC:1540,procURL=tcp://SERVER-1PC:1541,Pid=9596,Name=rmngr
30:00.932009-0,ATTN,2,process=ragent,OSThread=4168,Descr=Process will be killed,agentURL=tcp://SERVER-1PC:1540,procURL=tcp://SERVER-1PC:1541,Pid=9596,Name=rmngr,logOnly=0
30:16.064000-46993,PROC,2,process=ragent,OSThread=4168,Txt='Run process. Prog=C:\Program Files\1cv8\8.3.13.1690\bin\rmngr.exe, Command=("C:\Program Files\1cv8\8.3.13.1690\bin\rmngr.exe" -port 1541 -host SERVER-1PC -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo\\" -debug -tcp -fromsrvc -clstid 30364321-ea18-43e0-ab2a-012cc2dd1d87), success, pid=9788'
30:16.563068-31067,PROC,1,process=ragent,OSThread=4172,Txt='Run process. Prog=C:\Program Files\1cv8\8.3.13.1690\bin\rphost.exe, Command=("C:\Program Files\1cv8\8.3.13.1690\bin\rphost.exe" -range 1560:1591 -reghost SERVER-1PC -regport 1541 -pid dad66038-b049-4b9c-b654-e5246aae9361 -debug -tcp -fromsrvc), success, pid=6188'
30:16.579001-0,ATTN,3,process=ragent,OSThread=4168,Descr=Process is abandoned,agentURL=tcp://SERVER-1PC:1540,procURL=tcp://SERVER-1PC:1561,Pid=8676,Name=rphost
30:16.579002-0,ATTN,3,process=ragent,OSThread=4168,Descr=Process is abandoned,agentURL=tcp://SERVER-1PC:1540,procURL=tcp://SERVER-1PC:1541,Pid=9596,Name=rmngr
29:59.232003-0,PROC,1,process=rmngr,OSThread=7144,Err=0,Txt=1C:Enterprise 8.3 (x86-64) (8.3.13.1690) Cluster Manager (debug) started. Ctrl+C to exit.
30:12.695001-0,PROC,1,process=rmngr,OSThread=7144,Err=0,Txt=1C:Enterprise 8.3 (x86-64) (8.3.13.1690) Cluster Manager (debug) finished.
30:16.170003-0,PROC,1,process=rmngr,OSThread=10000,Err=0,Txt=1C:Enterprise 8.3 (x86-64) (8.3.13.1690) Cluster Manager (debug) started. Ctrl+C to exit.
30:16.642003-0,PROC,1,process=rphost,OSThread=9256,Err=0,Txt=1C:Enterprise 8.3 (x86-64) (8.3.13.1690) Working Process (debug) started. Ctrl+C to exit.
30:16.731034-0,PROC,1,process=rphost,OSThread=1588,Txt=Bad cluster lock.
30:16.934001-0,PROC,0,process=rphost,OSThread=3964,Txt='Process terminated.Stopped by console (working)'
30:16.934000-0,PROC,0,process=rphost,OSThread=3976,Txt='Process terminated.Stopped by console (working)'
30:19.258000-0,PROC,1,process=rphost,OSThread=10048,Err=0,Txt=1C:Enterprise 8.3 (x86-64) (8.3.13.1690) Working Process (debug) finished.
Показать"Stopped by console" - никакой консолью я не пользовался, 1С сама приняла решение завершить процесс.
Прикрепленные файлы:
Админы говорят, что возможно дело в Касперском, который работает на гипервизоре и влияет на работу виртуальных машин.
На выходных упал менеджер кластера без видимых причин, когда в базе не было никого, ни в ТЖ, ни в журнале сервера нет никаких подозрительных записей и ничего намекающего на причину падения. Т.е. в этом случае уже не 1С прибила процесс.
На выходных упал менеджер кластера без видимых причин, когда в базе не было никого, ни в ТЖ, ни в журнале сервера нет никаких подозрительных записей и ничего намекающего на причину падения. Т.е. в этом случае уже не 1С прибила процесс.
(27) Да, они есть. Часть из них относятся к падениям менеджера кластера и самих рабочих процессов, в момент работы системы бэкапирования. А часть относится к падениям процессов при обновлении конфигурации (ntdll.dll) и при обычной работе пользователей (inet.dll).
(31) Без реструктуризации. Нет ragent их не убивает. Менеджер кластера их тоже не убивает. Они натурально падают, да так, что исключений в ТЖ и дампов не оставляют. Единственные признаки - ошибка в журнале Windows и последующая запись в ТЖ - "Run Process" (когда новый экземпляр запускается)
(32) У меня точно такие же симптомы. ЕРП 2.4, платформа 8.3.17. ТЖ по упавшим процессам обрываются внезапно. В журнале ОС:
Имя сбойного приложения: rphost.exe, версия: 8.3.17.1549, метка времени: 0x5ef13317
Имя сбойного модуля: ntdll.dll, версия: 10.0.17763.1999, метка времени: 0x8a5eeabd
Код исключения: 0xc0000374
Смещение ошибки: 0x00000000000fa8f9
Идентификатор сбойного процесса: 0x1c3c
Время запуска сбойного приложения: 0x01d7f99f6e89e217
Путь сбойного приложения: C:\Program Files\1cv8\8.3.17.1549\bin\rphost.exe
Путь сбойного модуля: C:\Windows\SYSTEM32\ntdll.dll
Идентификатор отчета: bd04f4fa-35ab-4956-a394-4c64844e51d9
Попробовать обновить драйвера? Что еще можно сделать?
Имя сбойного приложения: rphost.exe, версия: 8.3.17.1549, метка времени: 0x5ef13317
Имя сбойного модуля: ntdll.dll, версия: 10.0.17763.1999, метка времени: 0x8a5eeabd
Код исключения: 0xc0000374
Смещение ошибки: 0x00000000000fa8f9
Идентификатор сбойного процесса: 0x1c3c
Время запуска сбойного приложения: 0x01d7f99f6e89e217
Путь сбойного приложения: C:\Program Files\1cv8\8.3.17.1549\bin\rphost.exe
Путь сбойного модуля: C:\Windows\SYSTEM32\ntdll.dll
Идентификатор отчета: bd04f4fa-35ab-4956-a394-4c64844e51d9
Попробовать обновить драйвера? Что еще можно сделать?
Итак падения процессов продолжаются. На этот раз валится рабочий процесс при каждом обновлении конфигурации в модуле windows ntdll.dll.
Примечательно то, что из 20 падений рабочих процессов, дамп сформировался для одного лишь менеджера кластера.
Примечательно то, что из 20 падений рабочих процессов, дамп сформировался для одного лишь менеджера кластера.
Отчитываюсь о решении одной из проблем. Менеджер кластера падал из-за старой версии драйвера чипсета установленного на гипервизоре. Уже как месяц полет нормальный.
Проблема "The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION" ушла после перехода на конфигурацию, где режим совместимости выставлен в 8.3.12. На платформе 8.3.13.1690 конфигурация в режиме совместимости 8.3.6 эту ошибку продолжает выдавать. Стало быть проблема в версии движка платформы.
Проблема "The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION" ушла после перехода на конфигурацию, где режим совместимости выставлен в 8.3.12. На платформе 8.3.13.1690 конфигурация в режиме совместимости 8.3.6 эту ошибку продолжает выдавать. Стало быть проблема в версии движка платформы.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот