Вопрос о включении отладки на продуктивном (рабочем) сервере — одна из вечных тем для споров между разработчиками и системными администраторами. Разработчикам нужен удобный инструмент для поиска ошибок, а администраторы опасаются за стабильность и производительность системы, которой пользуются десятки или сотни людей. Разберем, насколько обоснованы эти опасения и какие реальные риски несет включение отладки на сервере.
Самый серьезный и потенциально разрушительный инцидент, который может произойти из-за отладки на рабочем сервере, — это полная остановка работы пользователей. Проанализируем, как это происходит.
Представим ситуацию: разработчик для поиска ошибки ставит точку останова на строке кода, которая выполняется внутри транзакции. В этот момент в базе данных уже могут быть заблокированы важные таблицы (например, регистры остатков товаров, взаиморасчетов или бухгалтерии). Как только выполнение кода доходит до точки останова, отладчик останавливает его. Транзакция при этом не завершается и не отменяется, а "зависает" в ожидании действий разработчика.
Что происходит дальше? Все остальные пользователи, чья работа требует обращения к заблокированным таблицам, тоже "зависают". Их сеансы будут бесконечно ожидать снятия блокировки, которое не произойдет, пока разработчик вручную не продолжит выполнение кода (не нажмет F5 или F10 в конфигураторе). Если разработчик отвлекся, ушел на обед или просто не осознал последствий, это может парализовать работу целого отдела или даже всей компании на неопределенное время.
Именно этот риск является ключевым аргументом против отладки на "боевых" базах. Последствия такой остановки могут быть гораздо серьезнее, чем просто временное замедление работы.
Второй обоснованный повод для беспокойства — это снижение общей производительности системы. Даже если никто не использует отладчик активно, сам факт того, что сервер запущен с флагом отладки, влияет на его работу. Рассмотрим основные факторы замедления.
Отложенная загрузка метаданных.
В обычном режиме при старте рабочего процесса кластер серверов 1С загружает в оперативную память большой объем метаданных конфигурации. Это занимает время при запуске, но ускоряет дальнейшую работу.
В режиме отладки платформа меняет поведение: используется отложенная (ленивая) загрузка. Метаданные подгружаются в память не все сразу, а по мере необходимости, то есть при первом обращении к ним. Это действительно приводит к интересному побочному эффекту: сокращается время инициализации и снижается потребление оперативной памяти, что и замечают некоторые пользователи. Однако за это приходится платить. Для управления доступом к подгружаемым метаданным платформа использует дополнительные внутренние блокировки. На высоконагруженных системах с большим количеством одновременных сеансов эти блокировки могут создавать "узкое горлышко", замедляя работу всех пользователей.
Замедление выполнения кода 1С.
При включенной отладке каждая строка кода на встроенном языке выполняется немного дольше. Это связано с тем, что платформа выполняет дополнительные внутренние проверки, необходимые для работы отладчика (например, проверку, не установлена ли на этой строке точка останова). Этот "оверхед" (дополнительная нагрузка) накладывается на каждую исполняемую строку. Хотя на одной операции замедление может быть незаметным, в циклах или при выполнении ресурсоемких алгоритмов суммарный эффект становится ощутимым.
Особенности кэширования.
Существует мнение, что в режиме отладки перестает работать кэширование повторно используемых значений. Это означает, что функции, результаты которых в обычном режиме кэшируются для быстрого повторного доступа, в отладочном режиме могут выполняться каждый раз заново. Это также снижает потребление памяти, но увеличивает нагрузку на процессор и замедляет выполнение кода.
Насколько сильным будет замедление? Оценки разнятся. Некоторые говорят о единицах процентов, другие — о падении производительности до 20%. Важно понимать, что 20% — это очень существенное замедление для продуктивной системы. Точная цифра зависит от архитектуры конфигурации, характера нагрузки и "железа", но снижение производительности будет в любом случае.
Хотя это и относится к разряду "страшилок", некоторые специалисты отмечают, что включенный режим отладки может косвенно влиять на стабильность рабочих процессов (rphost). Есть мнение, что в этом режиме рабочие процессы чаще могут аварийно завершаться ("уходить в дамп"). Официально это не подтверждено как прямая причина, но при расследовании проблем со стабильностью и производительностью отключение отладки является одной из первых рекомендаций.
Опасения системных администраторов полностью обоснованы. Включение отладки на рабочем сервере создает реальные риски для стабильности и производительности, а также противоречит официальным рекомендациям фирмы "1С".
Рассмотрим, как правильно организовать процесс отладки.
Используйте тестовый контур. Это золотой стандарт разработки и администрирования. Необходимо иметь отдельный сервер (или виртуальную машину) с развернутой точной копией рабочей базы. На этом сервере можно безбоязненно включать режим отладки, ставить точки останова и проводить любые эксперименты, не мешая работе пользователей.
Различайте режимы. Важно понимать разницу между "сервер запущен в режиме отладки" и "к серверу подключен отладчик из конфигуратора". Первое вызывает постоянное снижение производительности. Второе добавляет к этому риск блокировок из-за точек останова.
Если отладка на "боевой" базе неизбежна. Бывают экстренные ситуации, когда ошибку нужно найти "здесь и сейчас", а воспроизвести ее на тестовой базе не получается. В этом случае действуем с максимальной осторожностью:
В конечном счете, удобство разработчика не должно ставиться выше стабильности работы всей компании. Планомерная работа с использованием тестовых сред — более профессиональный и безопасный подход, чем срочная отладка на работающей системе.