Почему при включении отладки на сервере 1С лавинообразно растут файлы логов?

Разберем нестандартную, но распространенную ситуацию администрирования серверов 1С:Предприятие 8.3. После включения режима отладки на сервере приложений системные администраторы часто замечают стремительное заполнение дискового пространства файлами логов в каталогах временных файлов или пользовательских профилей (например, C:\Users\USR1CV8...\AppData\Local\Temp\1c_logs). При отключении отладки рост прекращается. Выясним причину этой проблемы и рассмотрим способы её устранения.

Анализ проблемы: журнал регистрации или технологический журнал?

Первое заблуждение, с которым часто сталкиваются специалисты — путаница между штатным журналом регистрации (файлы формата *.lgd на базе SQLite) и технологическим журналом (текстовые файлы *.log). При попытке открыть растущие файлы средствами просмотра журнала регистрации можно получить ошибку формата или повреждения структуры:

sqlite3_step failed: database disk image is malformed

Однако если детально проанализировать ситуацию, выясняется, что неконтролируемо растут именно текстовые файлы *.log. Заглянем внутрь такого файла и посмотрим на типичное содержимое:

52:58.203594-0,EXCP,2,process=rmngr,t:clientID=836,t:applicationName=ServerProcess,t:computerName=wms,Exception=SeanceContextException,Descr='Сеанс отсутствует или удален ID=ff0f71ec-8b21-4067-974d-aaeb2c5dea97, File=src\SeanceContextBasImpl.cpp(7044)'
52:58.203595-0,EXCP,2,process=rmngr,t:clientID=836,t:applicationName=ServerProcess,t:computerName=wms,Exception=SeanceContextException,Descr='Сеанс отсутствует или удален ID=ff0ff316-6adb-4d64-81f0-226e6f0f0dc2, File=src\SeanceContextBasImpl.cpp(7044)'

Это классический формат записей Технологического журнала (ТЖ) платформы 1С. ТЖ активируется исключительно при наличии конфигурационного файла logcfg.xml. Если в системе ранее настраивался сбор логов и файл конфигурации остался активным, любое системное событие начинает непрерывно записываться на диск.

Почему логи растут именно при ключе -debug?

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

1. Постоянный опрос сеансов менеджером кластера: Когда служба сервера 1С запускается с параметром -debug, процесс менеджера кластера rmngr начинает непрерывно отслеживать контексты всех сеансов, фоновых заданий и клиентских подключений для регистрации точек останова и передачи отладочной информации.
2. Специфика короткоживущих сеансов: В нагруженных базах (особенно в системах WMS, при обмене через веб-сервисы, HTTP-сервисы или при частых регламентных заданиях) сеансы создаются и завершаются за доли секунды. Менеджер кластера rmngr пытается обратиться к контексту сеанса, который только что штатно закрылся.
3. Фиксация исключений: В результате обращения к уже закрытому сеансу платформа генерирует внутреннее исключение C++ SeanceContextException в исходном коде SeanceContextBasImpl.cpp с описанием "Сеанс отсутствует или удален". В штатном режиме платформа сама перехватывает и гасит это исключение, пользователи его не замечают. Но если в logcfg.xml включен сбор события EXCP без фильтрации, каждая подобная ситуация фиксируется в лог сотни раз в секунду.

Способ 1. Отключение или перенастройка файла logcfg.xml

Главным источником генерации файлов *.log является активный технологический журнал. Разберем шаги по его отключению или ограничению:

1. Перейдем в каталог конфигурационных файлов сервера 1С. Обычно файл находится по пути C:\Program Files\1cv8\conf\logcfg.xml (либо в подкаталоге конкретной версии платформы).
2. Если сбор диагностической информации больше не требуется, переименуем или удалим файл logcfg.xml. Платформа перечитывает настройки в течение одной минуты без необходимости перезапуска службы сервера.
3. Если сбор событий EXCP необходим для выявления других ошибок, настроим исключение для SeanceContextException, чтобы менеджер кластера не забивал журнал рутинными сообщениями:

<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\Users\USR1CV8.WMS\AppData\Local\Temp\1c_logs" history="2">
        <event>
            <eq property="name" value="EXCP"/>
            <ne property="Exception" value="SeanceContextException"/>
        </event>
        <property name="all"/>
    </log>
</config>

Обратим внимание на атрибут history="2": он ограничивает срок хранения логов двумя часами, что гарантирует защиту диска от переполнения.

Способ 2. Корректная организация режима отладки

Рассмотрим правила включения отладки на сервере приложений:

1. Не использовать отладку на продуктивных контурах: Постоянная работа кластера с параметром -debug приводит к дополнительным накладным расходам и снижению общей производительности системы. Отладку следует включать только на время локализации проблемы либо использовать выделенный контур разработки.
2. Использование выделенного сервера отладки: Начиная с платформы 8.3, отладку можно выносить в отдельный процесс с использованием протокола HTTP. Это позволяет изолировать отладочный трафик и снизить нагрузку на основной rmngr. Для этого в параметрах запуска агента сервера настраивается протокол (например, -debug -http).
3. Очистка кэша сеансов: При остановке службы сервера 1С рекомендуется очистить каталоги временных файлов пользователя, под которым работает служба (включая каталоги вида snccntx*), так как поврежденные кэшированные данные сеансов могут вызывать цикличные сбои в менеджере кластера.