Каждый разработчик 1С рано или поздно сталкивается с ситуацией, когда на рабочем (продуктивном) сервере необходимо локализовать сложную ошибку, воспроизводящуюся только на «боевых» данных. Единственный надежный способ сделать это быстро — запустить сеанс в режиме отладки. Однако системные администраторы часто встают на дыбы, наотрез отказываясь прописывать заветный ключ -debug в параметрах запуска службы сервера 1С. В качестве аргументов приводятся самые разные причины: от «у нас моментально переполнятся диски из-за логов» до «все пользователи тут же зависнут».
Давайте подробно разберем, где в аргументах системных администраторов кроется лукавство и непонимание архитектуры платформы 1С, а где — суровая техническая правда, пренебрежение которой может полностью парализовать работу предприятия.
Выясним первопричину классического заявления админов: «При включении отладки логи 1С начнут расти в геометрической прогрессии». Это утверждение является абсолютным заблуждением. В данном случае специалисты путают два принципиально разных механизма платформы:
-debug). Этот режим лишь открывает TCP/HTTP-порты на сервере приложений для подключения конфигуратора-отладчика и переводит рабочие процессы в состояние ожидания команд отладки. Платформа 1С при этом не начинает писать дополнительные события в свой стандартный Журнал регистрации (файлы .lgf или .lgd).logcfg.xml. Если настроить сбор ТЖ некорректно (например, собирать абсолютно все события без фильтрации по свойствам), то сервер действительно начнет генерировать гигабайты текстовых логов каждую минуту, что мгновенно забьет дисковую подсистему.Рассмотрим для примера структуру простейшего файла logcfg.xml, который настраивает ТЖ на сбор только критических ошибок. Такой лог не перегрузит систему:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\v8\logs" history="24">
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="All"/>
</log>
</config>
Таким образом, само по себе добавление ключа -debug в реестр или конфигурационный файл службы никак не влияет на дисковые логи самой платформы 1С.
Несмотря на то, что логи самой 1С не растут, админы могут быть косвенно правы относительно логов базы данных в СУБД (например, в MS SQL Server). И вот как это происходит на практике.
Проанализируем классический сценарий отладки. Разработчик ставит точку останова в модуле проведения важного документа (например, внутри процедуры ОбработкаПроведения). В этот момент на уровне СУБД открывается транзакция: все таблицы, участвующие в проведении (регистры накопления, бухгалтерии, сведений), блокируются СУБД для обеспечения целостности данных.
Пока программист не спеша ходит по строкам кода в отладчике, изучая значения переменных, происходят следующие процессы:
BEGIN TRAN)..ldf)..ldf начинает лавинообразно расти, поглощая все доступное дисковое пространство. На серверах с дефицитом места (например, когда свободно всего 50 ГБ) это гарантированно приводит к ошибке The transaction log for database is full и аварийной остановке СУБД.Посмотрим на условную схему кода, выполнение которого в отладчике замораживает транзакцию:
Процедура ОбработкаПроведения(Отказ, РежимПроведения)
// Блокировка таблиц СУБД начинается здесь
Движения.ТоварыНаСкладах.Записывать = Истина;
// Точка останова (Breakpoint) установлена на строке ниже:
// Пока разработчик думает, СУБД блокирует таблицы и раздувает файл .ldf
Для Каждого СтрокаТЧ Из Товары Цикл
// Производятся расчеты и запись движений
КонецЦикла;
КонецПроцедуры
В нормальном режиме работы сервер 1С компилирует программные модули конфигурации крупными блоками и кэширует их в оперативной памяти рабочих процессов rphost.exe. Это минимизирует количество обращений к СУБД за метаданными.
При включении режима отладки поведение системы существенно меняется:
В современных версиях платформы 1С v8.3 (особенно при использовании HTTP-отладки) за маршрутизацию сессий отладки отвечает отдельный процесс — сервер отладки dbgs (или встроенный в rphost модуль).
Если на сервере запущено множество баз и активно работают пользователи, включение HTTP-отладки создает постоянный фоновый трафик опроса (polling) между рабочими процессами сервера и конфигуратором. В некоторых релизах платформы (например, в ветках 8.3.18/8.3.19) фиксировались критические баги, при которых процесс dbgs.exe начинал бесконтрольно потреблять до 100% ресурсов процессора или приводил к утечкам оперативной памяти, что приводило к падению всего кластера 1С.
Рассмотрим реальный пример конфигурации «проблемного» сервера из сообщения №20 темы обсуждения:
Разберем по шагам, почему на таком сервере включение -debug гарантированно «убьет» производительность:
srvinfo). Очередь к диску вырастет, терминальные сессии пользователей начнут зависать в состоянии «Не отвечает».rphost.exe, что приведет сервер в состояние жесткого свопинга (сброса памяти на медленный диск).В такой ситуации системный администратор абсолютно прав: включать отладку на этом «живом» сервере категорически запрещено. Однако аргументировать это нужно не «ростом логов 1С», а аппаратным ограничением ресурсов и рисками глухих блокировок СУБД.
Что делать разработчику, если отладка жизненно необходима, а сервер слишком слаб или критически важен для бизнеса? Разберем основные альтернативные подходы:
Самый надежный и безопасный вариант. Разработчик выгружает резервную копию рабочей базы (файл .dt) или делает резервную копию средствами SQL и разворачивает ее локально на своем рабочем компьютере (в файловом варианте или на персональном сервере СУБД). Никакие действия разработчика не затронут реальных пользователей.
Если развернуть базу локально невозможно (например, из-за гигантского объема данных или интеграции с внешними системами), можно запустить на том же физическом сервере вторую службу «1С:Предприятие» на нестандартных портах (например, порты 1640, 1641 вместо стандартных 1540, 1541).
Для этой службы прописывается ключ -debug. В этот кластер добавляется только тестовая копия базы. Основной рабочий кластер продолжает функционировать на стандартных портах БЕЗ ключа отладки. Это защитит пользователей рабочей базы от случайных блокировок и падения производительности.
Если администраторы все же согласились временно включить -debug на рабочем сервере, разработчик обязан соблюдать строгие правила безопасности:
ОбработкаПроведения), записи элементов справочников (ПередЗаписью, ПриЗаписи) в периоды активной работы пользователей.ЗаписьЖурналаРегистрации()) вместо интерактивной отладки.