Серверная отладка 1С 8.3: флаг -debug, журналы и дампы

Обновлено 07.10.2026 · 9 мин

Содержание

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

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

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

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

🖥️ Вид базы. Флаг -debug нужен только клиент-серверной базе. В файловой базе серверный код выполняется в процессе клиента, и Конфигуратор отлаживает его без настроек.
🔑 Права. Нужны права администратора Windows (или root в Linux) на сервере и права на изменение службы.
🧭 Версия платформы. Узнайте точный номер: путь к ragent.exe содержит его, например C:\Program Files\1cv8\8.3.24.1548\bin\. Конфигуратор должен быть той же версии, что и сервер.
⏰ Окно для перезапуска. Договоритесь с пользователями о времени, когда можно перезапустить службу.
🌐 Порты. Для HTTP-отладки по умолчанию используется порт 1550. Если между рабочим местом разработчика и сервером есть файрвол, его нужно открыть.

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

Как включить отладку на сервере 1С: Windows и Linux

Windows: правка параметров службы

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

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

Задача — добавить в неё -debug. Есть два способа.

Способ 1. Через реестр.

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

Способ 2. Командой sc.

Посмотрите текущую строку запуска:

sc qc "1C:Enterprise 8.3 Server Agent (x86-64)"

Затем задайте новую. Пробел после binPath= обязателен, кавычки внутри экранируются обратной косой чертой:

sc config "1C:Enterprise 8.3 Server Agent (x86-64)" binPath= "\"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\""

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

Выбор протокола: TCP или HTTP

Флаг -debug без уточнений включает отладку по старому протоколу TCP. В современных версиях 8.3 рекомендуется HTTP-отладка: она работает через отдельный сервер отладки dbgs.exe, который агент запускает сам.

Вариант	Строка запуска	Когда подходит
TCP	`-debug` или `-debug -tcp`	Старые версии Конфигуратора, разовая отладка
HTTP	`-debug -http`	Современные версии 8.3, отладка через файрвол, работа из EDT
HTTP с адресом и портом	`-debug -http -debugServerAddr srv1c -debugServerPort 1550`	Несколько сетевых интерфейсов, нестандартный порт

Для HTTP-отладки можно задать пароль сервера отладки параметром -debugServerPwd. Если сервер доступен из общей сети, пароль стоит задать обязательно.

Linux: systemd или старый скрипт

В Linux порядок зависит от того, как установлен сервер.

🐧 Старый скрипт srv1cv83 в /etc/init.d/. Его параметры лежат в /etc/sysconfig/srv1cv83 (или /etc/default/srv1cv83 в Debian и Ubuntu). Там есть переменная SRV1CV83_DEBUG: установите ей значение 1 и перезапустите службу.
🐧 Юнит systemd (в свежих версиях платформы). Найдите юнит командой systemctl list-units | grep 1cv8, откройте его через systemctl edit --full <имя> и допишите -debug -http к строке ExecStart, где вызывается ragent.

После правки юнита выполните:

sudo systemctl daemon-reload
sudo systemctl restart <имя-юнита>

Как убедиться, что флаг применился

В Windows откройте «Диспетчер задач» → вкладка «Подробности», включите столбец «Командная строка». У процесса ragent.exe должен быть виден -debug.
При HTTP-отладке рядом появится процесс dbgs.exe.
Проверьте порт: netstat -ano | findstr 1550 в Windows или ss -tlnp | grep 1550 в Linux.

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

Флаг на сервере — половина работы. Вторую половину делает разработчик в Конфигураторе.

Откройте Сервис → Параметры → Отладка и выберите тот же протокол, что на сервере: TCP или HTTP. Для HTTP укажите адрес сервера отладки, например http://srv1c:1550.
Откройте Отладка → Подключение. В окне видны предметы отладки: клиентские сеансы, серверные сеансы, фоновые задания.
Нажмите «Автоматическое подключение» и отметьте нужные виды предметов: «Сервер», «Фоновое задание», при необходимости «HTTP-сервис» или «Web-сервис».
Запустите клиент из Конфигуратора (Отладка → Начать отладку) или подключитесь к уже работающему сеансу.

Если клиент запускается не из Конфигуратора, задайте ему параметры командной строки /DEBUG -http -attach /DEBUGGERURL "http://srv1c:1550". Сеанс сам подключится к серверу отладки.

Диагностика: выберите симптом

Журнал регистрации: максимум подробностей для анализа

Журнал регистрации — первый источник при разборе «что произошло в базе». По умолчанию в нём фиксируются не все события.

Как повысить детализацию:

В Конфигураторе откройте Администрирование → Настройка журнала регистрации.
Выберите уровень «Регистрировать все события». Это даёт максимум записей, включая примечания.
Здесь же задайте период разделения журнала, например «по дням», чтобы файлы не разрастались.

Где лежат файлы журнала в клиент-серверной базе: в каталоге кластера, обычно srvinfo\reg_1541\<идентификатор базы>\1Cv8Log\. Новый формат хранит журнал в файле .lgd (база SQLite), старый — в паре файлов .lgf и .lgp.

Смотреть журнал удобно из клиента: в БП 3.0 и ЗУП 3.1 это Администрирование → Обслуживание → Журнал регистрации. Фильтруйте по пользователю, событию «Ошибка» и интервалу времени.

Полный уровень детализации заметно увеличивает объём журнала. После разбора верните прежний уровень или настройте разделение по дням и чистку старых периодов.

Технологический журнал и замер производительности

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

ТЖ включается файлом logcfg.xml. Его кладут в каталог conf платформы, например C:\Program Files\1cv8\conf\. Сервер подхватывает изменения без перезапуска, примерно в течение минуты.

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

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

Что здесь происходит:

📁 location — каталог для логов. Выберите диск с запасом места, не системный.
🕒 history="24" — хранить логи 24 часа, старые удаляются автоматически.
⚠️ EXCP — все исключения на сервере.
🐢 DBMSSQL с duration от 1000000 — запросы к MS SQL дольше 1 секунды (в 8.3 длительность задаётся в микросекундах). Для PostgreSQL событие называется DBPOSTGRS.

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

Замер производительности. Пока идёт отладка, в Конфигураторе доступен Отладка → Замер производительности. Включите его, выполните медленную операцию в клиенте и остановите замер. Окно покажет строки кода с числом вызовов и долей времени, включая серверные модули. Без флага -debug на сервере серверная часть в замер не попадёт.

Утечки памяти и дампы рабочих процессов

Признаки утечки: память процесса rphost растёт часами и не освобождается, а после перезапуска рабочего процесса всё повторяется.

Что сделать в первую очередь:

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

Фрагмент logcfg.xml для поиска утечек:

<leaks collect="1">
  <point call="server"/>
</leaks>
<log location="D:\techlog_leaks" history="12">
  <event>
    <eq property="name" value="LEAKS"/>
  </event>
  <property name="all"/>
</log>

События LEAKS записываются при завершении серверного вызова, если объекты остались неосвобождёнными. В свойствах события будет контекст: модуль и строка.

Дампы при падении. Если rphost или ragent аварийно завершается, настройте создание дампов:

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

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

Внешние средства мониторинга и профилирования

Встроенных инструментов хватает не всегда. На сервере 1С полезны:

Инструмент	Что показывает	Когда брать
Системный монитор Windows (`perfmon`)	Память, процессор, диск по процессам `rphost`, `rmngr`	Долгое наблюдение за ростом памяти
Process Explorer	Дерево процессов, командные строки, потоки	Быстро проверить флаги и нагрузку
WinDbg	Содержимое дампов	Разбор аварийных падений
SQL Server Profiler, Extended Events	Тяжёлые запросы и блокировки в MS SQL	Если ТЖ указывает на СУБД
`pg_stat_statements`	Статистика запросов PostgreSQL	То же для PostgreSQL
`top`, `htop`, `journalctl`	Нагрузка и журналы служб в Linux	Сервер 1С на Linux

Для постоянного мониторинга используют и отраслевые системы, которые сами разбирают ТЖ и считают индекс APDEX. Они удобны при десятках пользователей, но сначала стоит освоить ручной разбор ТЖ: без него трудно понять, что именно показывает такая система.

Отладка на рабочей базе: риски и ограничения

Иногда ошибка воспроизводится только на рабочей базе. Тогда отладку включают и там, но с оговорками.

⛔ Точка останова в серверном коде останавливает сеанс пользователя. Если отлаживаемый сеанс держит блокировку, ждать будут и другие.
🐢 Флаг -debug добавляет накладные расходы. На загруженном сервере это заметно, поэтому после разбора флаг убирают.
🔓 Открытый сервер отладки — это доступ к данным. Через отладчик видны значения переменных, в том числе персональные данные. Закрывайте порт файрволом, задавайте пароль и не оставляйте отладку включённой «на всякий случай».
📦 ТЖ и дампы занимают диск. Переполненный диск на сервере 1С сам станет причиной аварии.

Порядок для рабочего сервера:

Отладка на рабочем сервере

Согласовать окно перезапуска службы с пользователями
Добавить -debug и перезапустить службу вне рабочего времени
Подключаться только к сеансу, где воспроизводится ошибка
Не ставить точки останова в общих модулях, которые вызывают все пользователи
Снять флаг -debug и перезапустить службу после разбора
Удалить logcfg.xml и очистить каталоги ТЖ и дампов

Выполнено: 0 / 6

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

Нужен ли флаг -debug для отладки файловой базы?

Нет. В файловой базе серверный код выполняется в процессе клиента, и Конфигуратор отлаживает его без настроек сервера.

Можно ли включить отладку для одной базы, а не для всего сервера?

Флаг -debug действует на весь агент сервера. Чтобы ограничить отладку, вынесите тестовую базу в отдельный кластер или на другой сервер.

Почему после обновления платформы отладка пропала?

Установщик новой версии регистрирует службу заново, со своей строкой запуска. Флаг -debug нужно добавить ещё раз.

Сколько оставлять включённым технологический журнал?

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

Чем отладка по HTTP лучше TCP?

Она проходит через один известный порт, работает с EDT и проще настраивается через файрвол. Для новых настроек выбирайте HTTP.

Помогла статья?