Сервер 1С падает: настройка сбора дампов (logcfg.xml), лимиты памяти и передача дампа в поддержку

Сначала о том, что это вообще такое. Когда процесс сервера 1С (например rphost) аварийно завершается, система может сохранить дамп - файл .mdmp со снимком памяти процесса в момент падения: какой код выполнялся, какие библиотеки были загружены, сколько занято памяти. По такому снимку можно понять, отчего процесс упал. Можно - если дамп собран правильно, а по умолчанию это не так. С этого и начнём.

Падает rphost или зависает сервер, в каталоге копятся файлы .mdmp, и непонятно, что с ними делать дальше. Разберу по шагам официальную диагностику: как настроить сбор пригодного дампа, как убрать частые причины падений штатными настройками кластера и как правильно передать дамп в поддержку 1С. Всё - документированными механизмами платформы и средствами ОС, без разбора внутренностей файла руками.

Материал на данных одной инсталляции: клиент-серверная, два узла кластера, платформа 8.3.27, Windows Server 2016, семь месяцев наблюдений.

Шаг 1. Настройте сбор дампов в logcfg.xml

Главная причина, по которой «дамп ничего не показал», - тип сбора по умолчанию. В файле logcfg.xml сервера (каталог conf, по умолчанию C:\Program Files\1cv8\conf\) тег дампа обычно стоит с минимальным типом:

<dump create="false" type="0" prntscrn="false"/>

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

<dump create="true" type="3" location="D:\1c-dumps"/>

При type="3" в дамп попадает контекст нити и данные исключения - то, ради чего его вообще снимают. Настройка официальная, описана на ИТС в разделе про технологический журнал и logcfg.xml.

Честно про цену. Дамп полного типа занимает примерно столько, сколько процесс держал памяти. При среднем 2,5-3 ГБ на процесс и двух десятках падений в месяц это порядка 50-60 ГБ в месяц, а один эпизод в наших данных дошёл до 41 ГБ разом. Поэтому location выносите на отдельный диск, а полный тип включайте временно, под отлов двух-трёх падений, и возвращайте обратно.

Шаг 2. Уберите частые причины настройками кластера

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

Лимиты памяти. Задайте в свойствах рабочего сервера «Максимальный объём памяти рабочих процессов» и «Безопасный расход памяти за один вызов». Лимит превращает аварию по памяти в управляемый перезапуск процесса: падение не исчезает, но перестаёт уносить чужие сеансы, а заодно уходит часть дампов нулевого размера (они пустые потому, что на запись файла памяти уже не оставалось).

Тут важно не спутать две цифры памяти. Резидент (WorkingSet) - то, что процесс физически держит в оперативной памяти, это показывает диспетчер задач. Коммит (PrivateUsage) - то, что процесс запросил у системы, независимо от того, вытеснено оно в подкачку или нет. Мониторинг, который следит только за резидентом, роста может не увидеть, а отказы «не удалось выделить память» считаются по коммиту. Поэтому следите за PrivateUsage, а не за WorkingSet.

Полнотекстовый индекс. Если пик падений приходится на ночное окно регламентных заданий, частый виновник - обновление полнотекстового индекса: вложения разбираются сторонними IFilter-библиотеками Windows прямо в адресном пространстве rphost, и повреждённый файл роняет процесс. Вынесите обновление индекса в отдельный рабочий процесс или ограничьте типы индексируемых файлов.

Чужой код в серверном процессе. Не тащите COM и .NET в рабочий процесс без нужды. Внешние компоненты подключайте файлом с диска, а не из макета - тогда у них будут нормальные имя и версия, и разбираться с ними проще. Отдельно: если в коде остался прямой доступ к СУБД через ADODB.Connection на драйвере sqlncli11.dll - он снят с поддержки Microsoft, замените на Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL).

Шаг 3. Снимите дамп для поддержки: procdump

Если процесс не падает, а зависает, ждать аварийного дампа бессмысленно - его сделать надо самому. Штатный способ - утилита procdump из пакета Sysinternals (Microsoft):

procdump -ma <PID> C:\1c-dumps\rphost.dmp

Ключ -ma снимает полный дамп процесса (со всей памятью) - именно такой нужен для анализа. PID рабочего процесса видно в консоли кластера или в диспетчере задач. Для отлова момента падения procdump умеет ждать исключение (-e) или превышение памяти по порогу - параметры есть в его справке.

Дальше дамп передаётся в поддержку 1С. Разбирать его самостоятельно не нужно и чаще всего бесполезно: если авария произошла внутри библиотеки самой платформы, поправить это может только вендор, а не вы в своей конфигурации. Приложите к обращению дамп полного типа, версию платформы и описание, при каких действиях воспроизводится. Один пригодный дамп даёт поддержке больше, чем гигабайты минимальных.

Один момент про безопасность перед отправкой: полные пути в дампе содержат имя сервера и учётной записи. Если прикладываете к обращению скриншоты или выдержки - помните об этом и не публикуйте инфраструктуру в открытых ветках.

Как оформить обращение в поддержку 1С

Когда дамп собран полным типом и авария повторяется, разбирать файл самому не нужно - его отдают в поддержку 1С. Чтобы обращение не вернулось с просьбой «пришлите ещё данных», сразу приложите к нему всё, что нужно для разбора:

• Сам дамп полного типа (type="3" или снятый через procdump -ma). Минимальный дамп бесполезен, об этом первый раздел.
• Точную версию платформы (например 8.3.27.1989) и разрядность процесса. Версия видна в консоли кластера и в имени файла дампа.
• Технологический журнал за момент аварии. Он настраивается тем же logcfg.xml: событие EXCP ловит исключения с текстом, а рядом видно, что процесс делал перед падением. Дамп показывает «где», журнал - «что происходило».
• Шаги воспроизведения: при каких действиях падает, регулярно или случайно, привязано ли к времени (ночные регламенты), к конкретной базе или пользователю. Даже «падает около 03:00 раз в сутки» сужает поиск.
• Окружение: версии ОС и СУБД, их разрядность, установленные внешние компоненты, сколько узлов в кластере.

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

Дампов нет вообще: пять причин, и все чинятся до следующего падения

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

• Сбор выключен. В теге стоит create="false". Самая частая и самая обидная: файл конфигурации правили, тип подняли, а флаг включить забыли.
• Каталогу нет прав. Служба сервера 1С работает под своей учётной записью, и если у неё нет права записи в каталог из location, дамп не пишется молча. Никакой ошибки вы не увидите. Проверяется просто: создайте в этом каталоге файл от имени той же учётки.
• Нет места на диске. Полный дамп размером с память процесса, а падают процессы обычно как раз распухшими. Три гигабайта свободного места на диске означают, что дампа не будет ни одного.
• location не задан. Тогда искать файлы надо не там, где привыкли, а рядом с каталогом технологического журнала из того же logcfg.xml. Каталог дампов обычно смотрят один, а пишутся они в другой.
• Процесс не падал. Самая коварная. Рабочий процесс, снятый кластером по превышению лимита памяти, завершается штатно, и дампа при этом не бывает по определению. Снаружи это выглядит одинаково: сеансы оборвались, люди ругаются. Различить можно по журналу регистрации: авария оставляет запись об ошибке, а плановое завершение по лимиту - нет.

Упал rphost, rmngr или ragent - это три разные аварии

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

• rphost - рабочий процесс, в нём живут сеансы пользователей. Его падение рвёт сеансы тех, кто на нём был, но кластер поднимет новый процесс сам. Неприятно, восстанавливается автоматически.
• rmngr - менеджер кластера: блокировки объектов, лицензирование, служебные сервисы. Его падение задевает всех, кто живёт на этом кластере, а не одну группу сеансов.
• ragent - агент сервера. Если упал он, сервер выпал из кластера целиком, и никакие рабочие процессы на нём уже не поднимутся.

Практический смысл различия такой. Одиночные падения rphost раз в сутки - это работа для настроек памяти из второго шага. Падения rmngr или ragent настройками лимитов не лечатся, и с ними идут в поддержку сразу, не пытаясь подобрать цифры.

И маленькая деталь, которая экономит полчаса при разборе: в имени файла дампа есть идентификатор процесса и время. По ним авария сопоставляется с записью в журнале регистрации и со строкой технологического журнала за ту же секунду. Дамп отвечает на вопрос где, журнал - что происходило, а связывает их именно это имя.

Шпаргалка: симптом - официальное действие

Коротко

1. Проверьте logcfg.xml до следующего падения: при type="0" дампы собираются без контекста исключения, разобрать их нельзя.
2. Поднимите тип до 3 временно, под отлов двух-трёх падений; location - на отдельный диск, полный дамп весит как память процесса.
3. Поставьте лимиты памяти рабочих процессов - авария становится управляемым перезапуском, уходят и пустышки.
4. Считайте по коммиту (PrivateUsage), а не по резиденту.
5. Зависание снимайте через procdump -ma; готовый дамп полного типа передавайте в поддержку 1С, а не разбирайте сами.

Из той же серии про эксплуатацию. Падения рабочих процессов разбираются по дампам, а вот интеграционный слой ломается иначе: за год в проде мы ни разу не упёрлись в производительность, зато трижды словили дефекты, которые копятся с аптаймом и на стенде не воспроизводятся. Разбор - Год с 1С:Шиной в проде: что ломается на длинном аптайме.

Другие наши инструменты диагностики 1С

• Карта объёмов базы 1С - из чего состоит база.
• Чек-ап СУБД - правильно ли она стоит на сервере.
• Трансформатор SQL → 1С - что делает конкретный запрос.
• Оптимизатор ВТ - как переписать то, что нашли.
• Аудит паролей СУБД - извлекаемость пароля СУБД из файла кластера, на чистом встроенном языке.