Ситуация, когда информационная база «зависает» на длительный период (от нескольких минут до полутора часов), является одной из самых сложных в практике администрирования 1С. Особенно остро проблема стоит в крупных конфигурациях, таких как Управление производственным предприятием (УПП), где задействовано множество фоновых процессов и сложные механизмы блокировок. В данной статье мы подробно разберем алгоритм поиска причин таких зависаний, проанализируем влияние аппаратной части, настроек СУБД и внутренних механизмов платформы 1С:Предприятие 8.3.
Первым шагом в диагностике является определение того, какой именно компонент системы испытывает перегрузку. Когда база перестает отвечать, нам необходимо зафиксировать состояние ресурсов сервера. Рассмотрим, на что именно стоит обратить внимание:
rphost и rmngr. Если rphost потребляет 100% процессорного времени, значит, выполняется тяжелый программный код или сложный запрос. Если же загрузка процессора низкая, но база «висит», мы имеем дело с блокировками (ожиданиями на ресурсах).Если анализ ресурсов показал, что проблема связана с СУБД, нам необходимо углубиться в мониторинг SQL Server. Рассмотрим основные инструменты:
MS SQL Profiler и Active Monitor: Посмотрим на текущие активные запросы. Нас интересуют длительные транзакции и типы ожиданий (Wait Types). Если мы видим множественные ожидания типа LCK_M_..., это явный признак блокировок на уровне таблиц базы данных. Также стоит обратить внимание на процессы, которые находятся в состоянии «Suspended».
Настройки параллелизма (MAXDOP): Одной из неочевидных причин «паралича» базы является неправильная настройка параметра Max Degree of Parallelism. Разберем ситуацию: если SQL Server пытается выполнить один тяжелый запрос, используя все доступные ядра процессора (значение 0), это может привести к взаимному ожиданию потоков (CXPACKET). Для стабильной работы 1С рекомендуется устанавливать MAXDOP в значение 1 или, в некоторых случаях, не более половины ядер на один запрос.
Ghost Cleanup: Выясним причину внезапных нагрузок после массового удаления данных. В MS SQL существует процесс Ghost Cleanup, который очищает «фантомные» записи. Если в УПП произошло масштабное удаление (например, очистка логов или помеченных на удаление объектов), этот фоновый процесс может начать конкурировать за ресурсы ввода-вывода, вызывая кратковременные зависания всей базы.
Часто зависания связаны с записью событий в Журнал Регистрации (ЖР). Посмотрим на формат вашего ЖР. В платформе 8.3 существует два формата: текстовый (.lgp) и новый на базе SQLite. Если текстовый файл разрастается до десятков гигабайт, любая попытка записи в него может приводить к микро-зависаниям, которые при определенных условиях превращаются в длительные паузы.
Если стандартный ЖР ничего не фиксирует в момент зависания, нам поможет Технологический Журнал (ТЖ). Для поиска причин зависания рекомендуется настроить сбор событий DBMSSQL, SDBL и особенно PROC. Рассмотрим пример настройки logcfg.xml для отслеживания длительных операций:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\LOGS\LONG_OPS" history="24">
<event>
<eq property="name" value="DBMSSQL"/>
<gt property="duration" value="10000000"/>
</event>
<event>
<eq property="name" value="SDBL"/>
<gt property="duration" value="10000000"/>
</event>
</log>
</config>
В данном примере мы настроили фиксацию всех обращений к СУБД, длительность которых превышает 10 секунд. Проанализировав полученные файлы, мы сможем увидеть конкретный SQL-запрос, который вызвал ожидание, и понять, к какой таблице он обращался.
Проанализируем состояние Полнотекстового поиска (ПТП). Если индекс ПТП поврежден или файлы индекса находятся на медленных дисках, регламентное задание по обновлению индекса может блокировать работу пользователей. Попробуйте временно отключить ПТП в консоли администрирования и понаблюдать за поведением системы. Если зависания прекратятся, необходимо выполнить очистку и полное перестроение индекса.
Также не стоит забывать об инфраструктурных факторах. Проверьте исключения антивируса на сервере 1С и SQL. В список исключений обязательно должны входить:
.mdf, .ldf).temp) пользователя, под которым запущены службы.srvinfo), где хранятся файлы журнала регистрации.Если антивирус или система теневого копирования (VSS) блокирует файл журнала регистрации для сканирования, сервер 1С встает в очередь на запись, что мгновенно «подвешивает» все активные сеансы, работающие с этой базой.
Выясним, нет ли в коде (например, в модулях сеанса или в доработанных механизмах обмена) обращений к внешним ресурсам. Если 1С выполняет запрос к внешнему API, COM-объекту или сетевому файлу, который недоступен, рабочий процесс будет ждать ответа до истечения таймаута TCP/IP. Рассмотрим ситуацию: внешняя система «уснула», а поток 1С заблокировал важный ресурс (например, таблицу констант или настроек) и ждет ответа. В этом случае база будет выглядеть зависшей для всех пользователей, хотя реальной нагрузки на процессор не будет.
Для поиска таких мест рекомендуется использовать метод «сигнальных сообщений» или логирования в текстовый файл в критических участках кода, связанных с интеграцией:
ТекстЛога = Новый ЗаписьТекста("C:\Logs\debug_exchange.txt", КодировкаТекста.UTF8, , Истина);
ТекстЛога.ЗаписатьСтроку("" + ТекущаяДата() + ": Начало вызова внешнего сервиса...");
// Вызов внешней компоненты или веб-сервиса
Результат = ВнешнийОбъект.ВыполнитьДействие();
ТекстЛога.ЗаписатьСтроку("" + ТекущаяДата() + ": Вызов завершен успешно.");
ТекстЛога.Закрыть();
Таким образом, комбинируя анализ системных ресурсов, мониторинг СУБД и детальную настройку технологического журнала, мы сможем локализовать причину даже самого длительного «зависания» и принять меры по его устранению.