В процессе эксплуатации серверных решений на платформе 1С:Предприятие 8.3 (особенно начиная с версий 8.3.24 и выше) системные администраторы часто сталкиваются с аномальным поведением службы отладки, что требует проведения замера производительности контура для точной диагностики. Процесс dbgs.exe (Debug Server) начинает бесконтрольно потреблять ресурсы центрального процессора, достигая 100% нагрузки на все ядра, и стремительно поглощает оперативную память. Ситуация осложняется тем, что проблема возникает спонтанно, даже когда активная отладка конфигурации не ведется.
В этой статье мы подробно разберем причины такого поведения, проанализируем взаимосвязь с новыми протоколами отладки и разработаем пошаговый план стабилизации работы сервера.
Начиная с последних релизов платформы 8.3, компания 1С активно внедряет новый механизм отладки по протоколу HTTP. В отличие от старого метода через TCP, HTTP-отладка позволяет проводить сессии через веб-серверы и прокси-соединения. Однако в релизах ветки 8.3.24 (в частности, в сборке 1368) данный механизм работает нестабильно.
Проанализируем ситуацию: процесс dbgs может уходить в бесконечный цикл при попытке опросить состояние так называемых зомби-сессий. Это сеансы пользователей, которые фактически уже завершены в кластере 1С, но информация о них осталась в базе данных сервера отладки. Наличие таких «подвисших» состояний часто требует ручного вмешательства или использования центра администрирования для управления сеансами. Пытаясь восстановить связь с несуществующим клиентом по HTTP, сервер отладки создает избыточную нагрузку на CPU. Кроме того, зафиксированы утечки памяти при работе с JSON-пакетами в рамках этого протокола.
Как показывает практика и опыт многих администраторов, самым надежным способом «успокоить» dbgs.exe является полный отказ от HTTP-отладки в пользу проверенного временем протокола TCP. Рассмотрим, как это сделать правильно.
Для изменения параметров нам потребуется отредактировать строку запуска службы сервера 1С в реестре Windows. Стоит отметить, что для подобных административных задач удобно иметь под рукой утилиту для быстрого запуска консоли кластера серверов. Разберем шаги:
regedit.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Remote Service (название может варьироваться в зависимости от версии).ImagePath.-http, удалите этот флаг.Рассмотрим пример правильной строки запуска для включения отладки по TCP:
"C:\Program Files\1cv8\8.3.24.1368\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" -debug
Обратите внимание, что мы используем только флаг -debug без дополнительных уточнений протокола. В этом случае платформа по умолчанию задействует TCP.
Если специфика вашей сети или требования разработчиков не позволяют отказаться от HTTP, мы можем попытаться стабилизировать работу сервера отладки, явно указав порты и формат вызова. Иногда конфликт возникает из-за того, что dbgs пытается динамически занять порт, который уже используется другим экземпляром платформы на этом же сервере.
Попробуем применить альтернативный синтаксис и зафиксировать порт отладки. В строке запуска службы заменим параметры на следующие:
/debug -http -debugServerPort 1555
Важные моменты, которые мы здесь учли:
/ вместо тире - перед словом debug (в некоторых сборках это помогает корректной интерпретации параметров).1555 (или любого другого свободного), чтобы исключить конфликты с основным диапазоном портов кластера 1560-1591.Рассмотрим ситуацию с точки зрения безопасности и стабильности. На «боевом» (продуктивном) сервере с большим количеством пользователей (более 100 человек) включенная отладка — это всегда риск. Она создает дополнительные накладные расходы, а общая стабильность системы зависит от многих факторов, включая корректное выполнение регламентных заданий.
Если отладка не требуется ежедневно, лучшим решением будет её полное отключение. Для этой задачи есть отладка кода без стандартного сервера отладки. Просто удалите все упоминания -debug или /debug из параметров службы. Это гарантирует, что процесс dbgs.exe вообще не будет запущен, и ресурсы сервера будут направлены исключительно на обслуживание запросов пользователей.
Иногда «бешенство» процесса dbgs вызвано внешними факторами. Проанализируем настройки операционной системы и окружения:
1. Исключения антивируса.
Антивирусные программы часто пытаются сканировать HTTP-трафик, который генерирует 1С. Поскольку отладка использует специфические JSON-структуры и веб-сокеты, антивирус может блокировать пакеты, вызывая таймауты и зацикливание dbgs. Необходимо добавить в исключения:
ragent.exe, rmngr.exe, rphost.exe, dbgs.exe.srvinfo).2. Настройка IPv6.
В ОС Windows Server 2016 часто наблюдаются проблемы, когда служба отладки пытается разрешить имена через протокол IPv6, что приводит к задержкам. Рекомендуется принудительно настроить систему на приоритет IPv4 или временно отключить IPv6 в свойствах сетевого адаптера для проверки гипотезы.
3. Очистка временных файлов отладки.
При аварийном завершении dbgs в каталоге данных сервера могут накапливаться поврежденные файлы конфигурации сессий отладки. Попробуем выполнить профилактическую очистку, которую также можно автоматизировать с помощью специализированных скриптов:
C:\Program Files\1cv8\srvinfo (или ваш путь к srvinfo).snaccfg).Если обновить платформу на более стабильную (например, 8.3.25.1257+) в данный момент невозможно, мы можем настроить «костыль» для автоматического реагирования. Создадим простой скрипт на PowerShell, который будет мониторить нагрузку и перезапускать службу. Подобный подход с мониторингом и оповещениями можно использовать и для контроля за дисковым пространством сервера — для этого есть готовая мониторинг журнала регистрации и уведомления в Telegram.
$processName = "dbgs"
$cpuThreshold = 80
$cpuUsage = (Get-Counter "\Process($processName)\% Processor Time").CounterSamples.CookedValue / $env:NUMBER_OF_PROCESSORS
Если ($cpuUsage -gt $cpuThreshold) {
Write-Host "Критическая нагрузка dbgs обнаружена. Перезапуск службы..."
Restart-Service "1C:Enterprise 8.3 Remote Service" -Force
}
Этот скрипт можно добавить в планировщик задач Windows с запуском каждые 10-15 минут. Это не решит коренную проблему, но позволит серверу оставаться в рабочем состоянии без участия системного администратора в ночное время.
Подводя итог, отметим, что наиболее эффективным методом борьбы с «безумием» dbgs.exe на платформе 8.3.24 является перевод отладки в режим TCP. Это возвращает стабильность системе и избавляет от неоправданных потерь производительности на сервере предприятия.