Отладка на сервере 1С:Предприятия: от ключа запуска до дампов rphost

Чтобы включить отладку сервера 1С, добавьте ключ -debug в строку запуска агента сервера ragent.exe и перезапустите службу. Без этого ключа Конфигуратор не видит серверный контекст: точки останова в модулях с &НаСервере молчат, а в списке предметов отладки нет серверных сеансов.

Ключ включает именно пошаговую отладку кода. Если же вам нужно понять, почему сервер падает, тормозит или ловит блокировки, отладчик не поможет. Тут работают другие инструменты: журнал регистрации, технологический журнал, дампы процесса rphost и консоль кластера. Ниже всё по порядку, от простого к тяжёлому.

Включение отладки на сервере 1С ключом -debug

Агент сервера стартует как служба. Режим отладки задаётся параметром в командной строке этой службы, а не галочкой в консоли кластера.

Windows

1. Откройте редактор реестра regedit от имени администратора.
2. Перейдите в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.
3. Найдите службу агента. Обычно она называется 1C:Enterprise 8.3 Server Agent (x86-64), у нестандартной установки имя может быть другим — сверьте его с оснасткой services.msc.
4. Откройте параметр ImagePath и добавьте -debug сразу после пути к ragent.exe.
5. Перезапустите службу.

Строка после правки выглядит примерно так:

"C:\Program Files\1cv8\8.3.24.1548\bin\ragent.exe" -debug -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo"

Номер версии и пути у вас свои. Менять порты и каталог srvinfo не нужно — трогаем только -debug.

Протокол: TCP или HTTP

У отладки два протокола:

Протокол на сервере и в Конфигураторе должен совпадать. Это самая частая причина, по которой «всё включено, а отладчик ничего не видит».

Linux

На старых релизах с init-скриптом режим включается переменной SRV1CV8_DEBUG=1 в файле /etc/sysconfig/srv1cv83 (в Debian-подобных системах — в /etc/default/srv1cv83). На актуальных релизах служба запускается через systemd:

1. Найдите юнит службы сервера командой systemctl list-units | grep 1C.
2. Посмотрите его файл: systemctl cat <имя-юнита>.
3. Добавьте -debug в строку ExecStart через systemctl edit --full <имя-юнита>.
4. Выполните systemctl daemon-reload и systemctl restart <имя-юнита>.

Предупреждение про обрыв сеансов действует и здесь.

Как проверить, что ключ применился

• 🔍 В Windows откройте Диспетчер задач → вкладка «Подробности» и добавьте столбец «Командная строка». У ragent.exe в строке должен быть -debug.
• 🔍 В Linux выполните ps aux | grep ragent — ключ виден в аргументах.
• 🔍 При протоколе HTTP на сервере появится процесс dbgs.

Подключение к отладке сервера из Конфигуратора

Ключ на сервере — половина дела. Вторая половина — настроить сам отладчик.

1. Откройте базу в Конфигураторе.
2. В Сервис → Параметры на вкладке отладки выберите тот же протокол, что на сервере.
3. Запустите клиент из Конфигуратора (F5) — он сразу подключится к отладке. Если пользователь запускает клиент сам, добавьте в параметры запуска /DEBUG.
4. Откройте Отладка → Подключение. В окне видны предметы отладки: клиентские сеансы, серверные контексты, фоновые задания.
5. Нажмите «Автоматическое подключение» и отметьте нужные типы — например, серверный контекст и фоновые задания. Тогда отладчик будет цепляться к ним сам.

Теперь точка останова в серверной процедуре срабатывает, как в файловой базе.

Учтите нагрузку. Сервер с ключом -debug работает медленнее, а любой, у кого есть доступ к Конфигуратору, может остановить серверный вызов на точке останова. На рабочем сервере держите отладку включённой только на время разбора и потом убирайте ключ.

Как выключить отладку после разбора

Порядок обратный: уберите -debug (и -http, если он был) из ImagePath или ExecStart, затем перезапустите службу в спокойное время. Проверьте командную строку ragent.exe ещё раз — ключа там быть не должно. Забытый ключ на рабочем сервере годами съедает производительность, и никто не помнит, откуда он взялся. Запишите в журнал работ, когда и зачем включали режим.

Журнал регистрации: что пишет сервер

Журнал регистрации — первый источник при разборе ошибок. Он хранится на сервере, в каталоге базы внутри srvinfo: reg_1541\<идентификатор базы>\1Cv8Log.

Уровень детализации задают в Конфигураторе: Администрирование → Настройка журнала регистрации. Варианты:

• ❌ «Регистрировать ошибки» — только ошибки;
• ⚠️ «Регистрировать ошибки и предупреждения»;
• 📝 «Регистрировать ошибки, предупреждения и информацию»;
• 📚 «Регистрировать все события» — максимум, включая примечания.

Для разбора сбоя временно поставьте «все события», воспроизведите проблему и верните прежний уровень. Полное логирование на большой базе быстро раздувает каталог.

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

Журнал покажет, кто и когда получил ошибку и в каком модуле. Но он не покажет, что происходило внутри процесса сервера. Для этого нужен технологический журнал.

Технологический журнал: настройка logcfg.xml

Технологический журнал (ТЖ) пишет события процессов сервера: исключения, вызовы, запросы к СУБД, блокировки. Включается файлом logcfg.xml.

Куда класть файл:

• 📁 Windows: каталог conf в папке конкретной версии платформы (C:\Program Files\1cv8\8.3.xx.xxxx\bin\conf) или общий C:\Program Files\1cv8\conf;
• 📁 Linux: /opt/1cv8/conf или каталог conf версии платформы.

Перезапускать службу не нужно — сервер перечитывает файл примерно раз в минуту.

Минимальная настройка для поиска ошибок:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\techlog\errors" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <event>
      <eq property="name" value="PROC"/>
    </event>
    <property name="all"/>
  </log>
</config>

Что здесь важно:

• location — пустой каталог только для ТЖ. Не указывайте папку, где лежит что-то ещё: сервер удаляет старые файлы по history.
• history="24" — сколько часов хранить логи. Без ограничения диск заполнится за пару дней.
• EXCP — исключения, PROC — события процессов: старт, остановка, аварийное завершение.

Файлы ТЖ — текст, по одному на час, в подкаталогах по процессам (rphost_1234, rmngr_5678). Для разбора удобно использовать grep, findstr или PowerShell — ищите по имени события и времени сбоя из журнала регистрации.

Рабочие процессы в консоли кластера

Консоль администрирования серверов показывает состояние процессов прямо сейчас. Путь: кластер → «Рабочие серверы» → нужный сервер → «Рабочие процессы».

На что смотреть:

Ограничения на память задаются в свойствах рабочего сервера: допустимый объём памяти и интервал превышения. Когда процесс выходит за предел, кластер переводит его в «выключенные», новые соединения уходят в другие процессы, а старый завершается.

Дампы памяти процесса rphost

Если rphost падает с ошибкой или пропадает из списка процессов, нужен дамп — снимок памяти в момент сбоя. Его разбирает поддержка или специалист с WinDbg.

Дампы включаются в том же logcfg.xml, отдельным элементом внутри <config>:

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

• create="true" — создавать дамп при аварийном завершении;
• location — каталог с запасом места: дамп весит столько же, сколько процесс занимал в памяти;
• type — состав дампа. Значение 3 даёт расширенный дамп, его обычно просят при обращении в поддержку.

Когда процесс не падает, а зависает, дамп снимают вручную: Диспетчер задач → правая кнопка по rphost.exe → «Создать файл дампа». В Linux применяют gcore с номером процесса.

Что приложить к дампу при разборе:

• 📌 точный номер версии платформы;
• 📌 фрагмент ТЖ с событиями EXCP и PROC за минуты перед падением;
• 📌 записи журнала регистрации того же времени.

Без версии платформы дамп бесполезен: его читают с отладочными символами конкретной сборки.

Блокировки и производительность сервера

Пользователи жалуются на «висит при проведении» — первым делом проверьте блокировки.

Консоль кластера. У каждой информационной базы есть узел «Блокировки»: видно, какой сеанс что держит. Для быстрой оценки этого хватает.

Технологический журнал. Для истории нужны события:

• 🔒 TLOCK — установка управляемой блокировки;
• ⏱ TTIMEOUT — ожидание блокировки закончилось таймаутом;
• 💥 TDEADLOCK — взаимоблокировка;
• 🐢 DBMSSQL или DBPOSTGRS — запросы к СУБД, отбирайте по длительности.

Пример отбора долгих запросов к MS SQL — дольше одной секунды:

<event>
  <eq property="name" value="DBMSSQL"/>
  <gt property="durationus" value="1000000"/>
</event>

Длительность в ТЖ указывается в микросекундах для платформы 8.3: 1 000 000 — одна секунда.

Счётчики Windows. Если узкое место не в 1С, а в железе, подключите Монитор производительности (perfmon): загрузка процессора, очередь диска, доступная память. Медленный диск под srvinfo или под временными файлами СУБД даёт те же симптомы, что и плохой код.

Частые ошибки при включении отладки

Частые вопросы