В процессе работы с крупными информационными базами, такими как 1С:ERP или 1С:Комплексная автоматизация, администраторы и разработчики часто сталкиваются с проблемой: при попытке сохранить или обновить файл в справочнике ДополнительныеОтчетыИОбработки система «замирает» на несколько минут. При этом мониторинг SQL Server показывает отсутствие значительной нагрузки, а сеанс пользователя в консоли кластера выглядит активным, но не совершающим операций с базой данных. В этой статье мы подробно разберем, почему возникают такие задержки и как их диагностировать с помощью технологического журнала.
Рассмотрим типичный сценарий: при записи обработки весом в несколько мегабайт программа подвисает на 2–5 минут. Посмотрим на строки технологического журнала (ТЖ), которые фиксируют разрыв во времени. В логах мы видим вызовы интерфейсов IClusterLocks и IDebugConnection.
Проанализируем фрагмент лога, предоставленный в проблеме:
05:45.807004-1,SCALL,2,process=rphost,p:processName=ERP_2017, ... IName=IClusterLocks,Method=3,MName=getDynDataList
...
07:42.245015-116438010,SCALL,2, ... IName=IClusterOperativeTimestamp,Method=3,MName=clearObjectsByKeys
Обратим внимание на разницу во времени между этими событиями. Метод getDynDataList и последующий clearObjectsByKeys указывают на то, что система в данный момент занимается инвалидацией (очисткой) кэша метаданных. Когда мы записываем дополнительную обработку, сервер 1С должен оповестить все рабочие процессы (rphost) в кластере о том, что объект изменился. Если в кластере настроено много рабочих процессов или сеансов, время на синхронизацию кэша метаданных между ними резко возрастает.
Одной из скрытых причин «тормозов» является активный режим отладки на сервере приложений. В логах мы видим вызов IDebugConnection::transmitDebugCommand. Разберем подробнее, почему это критично:
.epf). При включенной отладке (параметр -debug в строке запуска службы сервера) сервер тратит значительное время на передачу состояния объектов и самого тела обработки отладчику.IDebugConnection, заставляет систему выполнять дополнительные проверки прав и состояний объектов при их модификации.Рекомендация: Для проверки гипотезы попробуйте временно перезапустить службу сервера 1С без флага -debug и повторить запись обработки. Если скорость записи нормализуется, необходимо использовать отладку только на тестовых контурах.
Часто зависание происходит не в момент записи данных в таблицу SQL, а сразу после. Рассмотрим ситуацию, когда отладчик успешно проходит строку Записать(), но управление не возвращается в форму еще долгое время. Выясним причину, изучив код типовых конфигураций. В ERP при записи объекта справочника срабатывают подписки на события.
Посмотрим на пример кода, где может происходить задержка:
// Процедура в модуле формы или в подписке
Процедура ПриЗаписиНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
// Вызов служебных механизмов БСП
ЗаметкиПользователяСлужебный.УстановитьСнятьПометкуУдаленияЗаметок(ТекущийОбъект);
КонецПроцедуры
В современных версиях БСП при записи объекта может инициироваться целый каскад действий:
Если сервер нагружен (высокий процент использования CPU), фоновые задания, отвечающие за эти операции, выстраиваются в очередь. Основной сеанс пользователя переходит в состояние Wait, ожидая завершения критических участков кода в фоновом режиме. Снижение общей нагрузки на процессор (как в решении автора темы) часто «лечит» проблему, так как освобождаются кванты времени для быстрых фоновых потоков.
Если запись длится несколько минут, а SQL-трафик отсутствует (как заметил автор в сообщении 10), проанализируем состояние файлов сервера приложений. При сохранении бинарных данных (обработок) сервер 1С создает временные файлы в каталоге AppData профиля пользователя, под которым запущена служба ragent.
Разберем по шагам, что может мешать процессу:
.tmp, в который разворачивается обработка перед записью в базу.Управление полнотекстовым поиском и проверить скорость записи.IClusterLocks может медленно отрабатывать, если сервер пытается обратиться к менеджеру кластера (rmngr) по протоколу IPv6, не получая быстрого ответа. Выясним, настроен ли приоритет IPv4 в операционной системе.Для того чтобы устранить тормоза при записи дополнительных обработок, выполним следующие шаги:
snacc и временные файлы в каталоге srvinfo. Это исключит влияние старого «мусора» от динамических обновлений.-debug.ПередЗаписью. Важно смотреть время выполнения до самого конца серверного вызова, включая обработчики ПриЗаписи и ПослеЗаписи.logcfg.xml на сбор событий EXCP (исключения) и ATTN (предупреждения), чтобы увидеть возможные неявные ошибки сетевых интерфейсов кластера.Соблюдение этих рекомендаций позволит сократить время записи объектов с нескольких минут до нескольких секунд, обеспечив стабильную работу пользователей в системе.