Дампы аварийного завершения процессов 1С — 10 августа 2026 г. в 01:23:43.540
Дампы аварийного завершения процессов 1С В последнее время достаточно часто сталкиваемся с тем что сбор дампов или не настроен, или настроен не совсем верно, или приводит к окончанию места на диске... А тем временем причину падения процесса без разбора дампа понять бывает или очень трудно или вообще невозможно. Так как же настроить сбор дампов и сделать так чтобы это не приводило к падению сервера по нехватке места на диске? В настройке ТехЖурнала (файл logcfg.xml) для сбора дампов в ОС Windows (в Linux всё по другому ) нужно добавить/отредактировать строку: <dump location="D:\dumps\" create="1" type="3" externaldump="1"/> Тип дампа (type) нужно поставить 3, так как это минимально необходимый объём информации для действенного разбора дампа. Дамп такого типа при формировании будет иметь размер равным размеру оперативной памяти, которую занимал процесс на момент формирования дампа. Очень важно указать location не на системном диске С и не на диске где у нас расположены сеансовые данные и/или каталог временных файлов пользователя процесса rphost. Желательно выделить для этого отдельный логический/физический диск с объёмом свободного места не менее всего объёма оперативной памяти, так как в крайнем случае дамп будет размером во всю оперативку. Затем нужно сделать скрипт и поставить его в шедуллер на выполнение раз в 5 минут (меньше получится только используя cron, там раз в минуту), который будет архивировать файл дампа. Архив дампа очень часто занимает в десять раз меньше места чем оригинал. Настроить систему мониторинга или в самом скрипте архивации прописать сообщение ответственному админу 1С о факте формирования дампа. Что делать с дампами потом и какие они бывают? Дамп в ОС Windows имеет достаточно понятное имя файла: <имя процесса>_<версия платформы>_<смещение>_<годмесяцденьчасминутасекунда>_<PID процесса>.mdmp Например: rphost_8.3.27.1606_547f1b52_20260810051328_13432.mdmp Сформированный архив дампа нужно отправить в 1С с полным описанием всей ситуации падения, если оно есть, только там смогут указать причину падения. В имени много важной информации, и отдельно нас интересует смещение. Если у нескольких дампов смещение одинаковое, то и причина падения с 99% вероятностью тоже одна, поэтому на расследование достаточно отправить пару дампов, а остальные просто сохранить в сторонке. Если же смещение _00000000_, то такой дамп отправлять никуда не нужно. Тут причина падения заранее известна и заключается в том, что процесс был убит Системой отслеживания разрыва соединений Это поведение зависит от настроек кластера 1С (на скриншоте), а именно: ❗Менять их нужно крайне осознанно полностью понимая что делаешь, несколько раз прочитав документацию и поняв её! Принудительно завершать проблемные процессы - если выключим, то таких дампов и не будет, так как и система отслеживания по факту прекратит работу. Так можно делать только в крайних случаях, когда формирование дампов множественное, все они со смещением 00000000 и мешают работе системы. Другие настройки это Период проверки (1000 мс) и Таймаут проверки (5000 мс), вот их нужно кратно увеличить до тех пор пока падения не прекратятся. НО, сам факт таких дампов говорит о том что процессы реально не отвечают системе отслеживания и с этим нужно разбираться. И о УЖАС - разбираться с этим нужно АДМИНИСТРАТОРАМ 1С, а не 1С-кам!!! Вот выдержка из документации (ссылка выше), которая с этим поможет: Для этого каждые 10 секунд в технологический журнал записывается статистика проверки соединений за прошедшие 10 секунд. В частности, выводится информация о среднем времени ответа и о максимальном времени ответа. Эта информация позволяет выставить оптимальные значения таймауты проверки, которые не будут приводить к ложным срабатываниям системы проверки, но, в тоже время, обеспечат надежное функционирование самой системы. В технологическом журнале информация фиксируется в событии CONN.