В работе крупных информационных систем на базе 1С часто возникают ситуации, когда производительность резко падает в определенные часы. Одной из наиболее загадочных проблем является циклическое зависание базы, например, ежедневно в 14:00, которое сопровождается появлением странных сеансов DefUser и требует принудительной перезагрузки сервера. В данной статье мы подробно разберем, почему это происходит, проанализируем роль регламентных заданий и выясним, как правильно обслуживать базу данных, если вы используете SQL Express.
Рассмотрим стандартную ситуацию: сервер обладает достаточным запасом оперативной памяти (16 Гб и выше), современным процессором уровня i7, а количество пользователей не превышает 10 человек. Несмотря на отличные показатели теста Гилева, система начинает «колом» вставать в середине рабочего дня. При этом процессы sqlservr.exe и rphost.exe начинают потреблять значительные ресурсы, а в консоли кластера 1С множатся сеансы с именем DefUser.
Проанализируем природу этих сеансов. Появление DefUser в «1С:Документообороте» чаще всего свидетельствует о работе внешних подключений. Это могут быть:
Если зависание происходит ровно в 14:00, это указывает на срабатывание триггера. Это может быть либо запланированная синхронизация на стороне другой программы, либо накопление критического объема изменений в таблицах, которое делает текущие планы запросов SQL неэффективными.
Первым делом мы должны исключить влияние внутренних механизмов 1С. Разберем, как правильно проверить активность базы. Перейдем в типовую обработку «Регламентные и фоновые задания». В списке необходимо нажать кнопку «Еще — Показать все», чтобы увидеть скрытые системные процессы.
Особое внимание стоит уделить вкладке «Фоновые задания». Мы рекомендуем отфильтровать список по времени начала (именно около 14:00) и состоянию «Выполняется». Однако, как показывает практика, зависание может вызвать не само задание, а его последствия для базы данных. Проанализируем Журнал регистрации (ЖР) за этот период, обращая внимание на события SCOM (COM-соединения) и EXCP (исключения).
В конфигурации «1С:Документооборот» критически важным является Полнотекстовый поиск (ППД). Даже если регламентное задание по индексации настроено на ночь, система может пытаться обновлять индекс порциями в течение дня. Если индекс поврежден, это вызовет колоссальную нагрузку на дисковую подсистему и процессор.
Выясним причину, по которой стандартные методы оптимизации могут не работать. В версии SQL Express отсутствует компонент SQL Server Agent, а значит, встроенные «Планы обслуживания» (Maintenance Plans) недоступны. Без регулярного ухода база данных начинает «деградировать»:
Рассмотрим, почему это приводит к зависанию именно в 14:00. К середине дня пользователи успевают создать и изменить значительное количество документов. Когда объем изменений достигает определенного порога, старая статистика окончательно перестает соответствовать реальности, и очередной сложный запрос (например, построение дерева задач) «подвешивает» весь процесс rphost.
Поскольку автоматических планов обслуживания нет, нам необходимо создать их вручную. Для этого воспользуемся связкой из SQL-скрипта и системного Планировщика задач Windows. Рассмотрим пример скрипта для дефрагментации всех индексов в базе данных.
-- Скрипт для реиндексации всех таблиц базы данных
DECLARE @TableName varchar(255)
DECLARE @TableCursor CURSOR
SET @TableCursor = CURSOR FOR
SELECT table_name
FROM information_schema.tables
WHERE table_type = 'BASE TABLE'
OPEN @TableCursor
FETCH NEXT FROM @TableCursor INTO @TableName
WHILE @@FETCH_STATUS = 0
BEGIN
PRINT 'Reindexing ' + @TableName
EXEC('ALTER INDEX ALL ON ' + @TableName + ' REBUILD')
FETCH NEXT FROM @TableCursor INTO @TableName
END
CLOSE @TableCursor
DEALLOCATE @TableCursor
Для реализации этого решения по шагам выполним следующие действия:
.sql (например, maintenance.sql).run_maint.bat, который будет запускать выполнение скрипта через утилиту sqlcmd:
sqlcmd -S SERVERNAME\SQLEXPRESS -i "C:\Scripts\maintenance.sql"Важный момент: Помимо реиндексации (REBUILD), крайне важно выполнять обновление статистики. Для этого можно использовать команду EXEC sp_updatestats. Это позволит SQL-серверу всегда иметь актуальную информацию о распределении данных в таблицах 1С.
Чтобы минимизировать последствия «тяжелых» запросов и исключить бесконечное размножение сеансов DefUser, проанализируем настройки рабочего сервера в консоли администрирования 1С. Рекомендуется установить следующие параметры для рабочего процесса:
rphost.Если реиндексация помогла лишь частично, нам стоит настроить сбор Технологического журнала (ТЖ). Нас интересует событие DBMSSQL, которое покажет наиболее длительные запросы к базе данных. Создадим файл logcfg.xml в папке conf сервера 1С с минимальными настройками для отслеживания долгих запросов (более 20 секунд).
<config xmlns="http://v8.1c.ru/7.4/puls/conf">
<log location="C:\LOGS\LONG_QUERIES" history="24">
<event>
<eq property="Name" value="DBMSSQL"/>
<gt property="Duration" value="20000000"/>
</event>
<property name="AllProperties"/>
</log>
</config>
Проанализировав полученные логи после очередного «часа X» (14:00), мы сможем точно увидеть, какая таблица или какой метаданный объект (документ, бизнес-процесс) инициирует сложный запрос. Часто оказывается, что пользователи начинают пользоваться поиском по неиндексированным реквизитам, что в условиях фрагментированной базы SQL Express приводит к фатальным блокировкам.
Зависание 1С в одно и то же время — это почти всегда признак сочетания двух факторов: накопления нагрузки (активность пользователей к обеду) и отсутствия технического обслуживания СУБД. Выполнение дефрагментации и реиндексации является обязательным условием эксплуатации любой базы на SQL-сервере. Даже если вы используете бесплатную версию Express, механизмы автоматизации через sqlcmd позволяют поддерживать систему в здоровом состоянии, обеспечивая комфортную работу пользователям «1С:Документооборота» без ежедневных перезагрузок.