Серверная отладка 1С: от запуска агента до разбора дампа

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

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

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

Что проверить на сервере перед отладкой

Сначала убедитесь, что версии совпадают. Платформа на клиенте, где открыт конфигуратор, и платформа на сервере должны быть одной сборки (например, 8.3.xx.yyyy целиком). Расхождение в последней группе цифр уже даёт странные отказы подключения.

Короткий список подготовки:

• 🖥 Отдельная копия базы. Отладку лучше вести на тестовой базе или на копии рабочей. Остановленный на точке останова поток держит блокировки.
• 🔌 Порты. Должны быть доступны порт агента кластера (по умолчанию 1540), диапазон портов рабочих процессов (1560–1591) и порт сервера отладки. Между клиентом и сервером проверьте брандмауэр.
• 👤 Права. Пользователь, под которым запущена служба сервера, должен читать и писать в каталоги журнала и дампов. Пользователь информационной базы, под которым вы заходите, должен иметь право на отладку, то есть роль с правами «Администрирование» или аналогичную.
• 💾 Место на диске. Журнал с подробными событиями за час легко занимает несколько гигабайт, дамп памяти рабочего процесса — столько же, сколько он занимает в оперативной памяти.
• 🕒 Окно работ. Согласуйте время: отладка или сбор дампа — это остановка части сеансов.

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

Запуск сервера с ключом отладки

Служба «Агент сервера 1С:Предприятия» запускается с параметрами командной строки. Для отладки к ним добавляют ключ -debug. Если сервер установлен как служба Windows, параметры правят в реестре, в строке ImagePath ветки службы. Перед правкой экспортируйте ветку: ошибка в строке запуска не даст службе стартовать.

Типичный фрагмент строки запуска:

ragent.exe -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "D:\srvinfo" -debug

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

Какой режим отладки выбрать

Платформа поддерживает два протокола связи отладчика: по TCP и по HTTP. Протокол задают в запуске клиента и в параметрах конфигуратора. На практике выбирают так:

Если отладка «не цепляется» через TCP, проверьте, что имя сервера, под которым вы подключаетесь, разрешается в правильный адрес. Часто мешает неверная запись в файле hosts или несколько сетевых карт на сервере.

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

Откройте конфигуратор нужной базы и запустите отладку из меню «Отладка». Запуск через 1С:Предприятие в режиме отладки откроет клиентское приложение, а точки останова в серверных модулях сработают на сервере.

Порядок действий:

1. В модуле, который выполняется на сервере, поставьте точку останова слева от нужной строки.
2. Запустите отладку и воспроизведите действие в клиенте.
3. Когда срабатывает точка, окно конфигуратора выходит на передний план. Смотрите значения в окне «Вычислить выражение» и в стеке вызовов.
4. Продолжайте пошаговое выполнение. Серверный вызов с клиента при этом ждёт.

💡 Точка останова в общем модуле с флагом «Вызов сервера» срабатывает, только если вызов действительно идёт на сервере. Если код выполняется на клиенте, отладчик его на сервере не покажет, и это самая частая причина «не останавливается».

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

Журнал пишет события платформы в текстовые файлы. Он нужен там, где отладчик не помогает: нет возможности воспроизвести, сбой плавающий, ошибка на стороне СУБД.

Файл logcfg.xml

Настройка журнала лежит в файле logcfg.xml в каталоге conf рядом с установленной платформой. Минимальная настройка для сбора исключений:

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

Здесь location — каталог, куда пишутся логи, history — сколько часов хранить файлы. Событие EXCP — исключения. Изменения подхватываются без перезапуска службы, обычно в течение минуты.

Какие события включать

Не включайте всё сразу. Выбирайте события под симптом:

• ❗ EXCP — исключения и тексты ошибок.
• 🐢 CALL, SCALL — серверные вызовы, длительность. Отсекайте быстрые по свойству durationus.
• 🗄 DBMSSQL — запросы к СУБД с текстом и временем.
• 🔒 TLOCK, TTIMEOUT, TDEADLOCK — управляемые блокировки, таймауты и взаимоблокировки.
• 📉 QERR — ошибки запросов.

Для длительных операций добавляйте фильтр по длительности, иначе журнал разрастётся за час:

<event>
  <eq property="name" value="CALL"/>
  <ge property="duration" value="3000000"/>
</event>

Длительность в журнале измеряется в микросекундах, то есть значение выше означает три секунды.

Как читать файлы

Каждая запись начинается со времени и длительности, затем имя события и свойства через запятую. Искать удобно по идентификатору сеанса или по тексту ошибки. Для больших объёмов используют сторонние разборщики журнала, но для первой диагностики хватает поиска по каталогу:

findstr /s /i /c:"Descr=" D:\1clogs\*.log

Дампы памяти: зависания и аварийные остановки

Дамп — снимок памяти процесса. Он нужен, когда рабочий процесс завис, ушёл в 100% процессора или аварийно завершился без внятного сообщения. Дамп отдают разработчикам платформы или разбирают сами в отладчике для Windows.

Автоматический дамп при аварии

В logcfg.xml добавьте секцию, и платформа сама создаст дамп при критической ошибке:

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

Тип 3 даёт полный дамп с максимальной информацией, но такой файл большой. Для первого раза хватит мини-дампа, а полный нужен, если просят специалисты по платформе.

Дамп зависшего процесса вручную

1. Диспетчер задач → вкладка «Подробности».
2. Найдите rphost.exe, который съел процессор или завис. Если их несколько, ориентируйтесь на потребление ресурсов и на PID из журнала.
3. Правый клик → «Создать файл дампа».
4. Файл появится во временной папке пользователя. Переместите его на отдельный диск.

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

Не отправляйте дамп посторонним без согласования. В памяти процесса остаются данные базы, включая персональные.

Где тормозит: замеры производительности

Если нужна не ошибка, а скорость, начинайте с цифр, а не с догадок. Три уровня измерения:

Что смотреть на сервере

• 🔴 Загрузка процессора рабочих процессов постоянно выше 80–90% — узкое место в вычислениях или в числе пользователей на процесс.
• 🟠 Очередь к диску выше двух на ядро — тормозит диск, в первую очередь под СУБД.
• 🟡 Нехватка оперативной памяти и активный своп — рабочие процессы перезапускаются по превышению лимита.

Метод от общего к частному

1. Найдите период замедления по жалобам пользователей.
2. В журнале за этот период отсортируйте CALL по длительности.
3. Для самых долгих вызовов найдите связанные DBMSSQL: если время ушло в СУБД, смотрите запрос; если нет — процедуру в самом коде.
4. Только после этого меняйте код или индексы.

💡 Встроенный механизм «Замер производительности» в конфигурациях БСП помогает увидеть ключевые операции в разрезе по дням, не включая подробный журнал. Он подходит для постоянного наблюдения, журнал — для разовой диагностики.

Типичные сбои при серверной отладке

Отладка в облаке и у провайдера

Если база размещена в облачном сервисе или у хостера, доступа к ragent и к каталогам журнала у вас, как правило, нет. Поэтому возможности зависят от провайдера.

Что обычно доступно:

• 🧪 Отладка на копии базы, развёрнутой у вас: выгрузите базу в файл .dt и загрузите на собственный тестовый сервер.
• 📨 Запрос журнала или дампа у поддержки провайдера: укажите время сбоя с точностью до минуты, имя пользователя и текст ошибки.
• 📎 Описание сценария воспроизведения: что нажали, в каком документе, с какими данными.

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

Автоматизация: скрипты и сбор диагностики

Ручной сбор при каждом сбое быстро надоедает. Обычно автоматизируют три задачи.

Периодическая очистка журнала

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

forfiles /p D:\1clogs /s /m *.log /d -3 /c "cmd /c del @path"

Команда удаляет файлы старше трёх дней. Проверьте её сначала с заменой del на echo.

Сбор состояния кластера

Утилита администрирования rac из состава сервера отдаёт список сеансов, процессов и блокировок. Простейший сценарий: по расписанию сохранять список сеансов в файл, чтобы видеть, кто был в базе в момент сбоя.

rac session list --cluster=<идентификатор_кластера> > D:\diag\sessions.txt

Идентификатор кластера получают командой rac cluster list. Для работы нужен запущенный сервер администрирования ras.

Дамп по условию

Скрипт проверяет потребление процессора rphost.exe, и если оно выше порога несколько проверок подряд, создаёт дамп утилитой командной строки и пишет событие в журнал. Порог выбирайте по нормальной нагрузке сервера: например, если в обычный день процесс держится на 40–60%, ставьте порог 95% на три проверки подряд раз в минуту.

Правила работы с журналом и отладкой

Несколько привычек сэкономят часы:

1. Включайте журнал под конкретный симптом и выключайте после сбора.
2. Фиксируйте время начала и конца воспроизведения: так легче найти нужный участок среди гигабайтов записей.
3. Храните logcfg.xml в системе контроля версий вместе с примечанием, зачем включён каждый блок.
4. Не отлаживайте на рабочей базе то, что можно воспроизвести на копии.
5. После работы верните сервер в обычный режим запуска, без -debug.

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