Сервер 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 раз в сутки» сужает поиск.
• Окружение: версии ОС и СУБД, их разрядность, установленные внешние компоненты, сколько узлов в кластере.

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

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

Коротко

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

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

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

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