Что делать, если зависает 1С у пользователей и растет показатель «Захвачено СУБД»?

Каждый администратор систем «1С:Предприятие» рано или поздно сталкивается с ситуацией, когда стабильно работающая система внезапно начинает зависать. Пользователи жалуются на «песочные часы», проведение документов останавливается, а при попытке зайти в консоль администрирования кластера мы видим пугающую картину: у одного или нескольких сеансов стремительно и непрерывно растет показатель «Захвачено СУБД» в секундах. При этом попытка принудительно завершить сеанс зависшего пользователя приводит к мертвой блокировке самой консоли кластера, а единственным спасением кажется полная перезагрузка службы Агента сервера 1С. Но уже через 20 минут ситуация повторяется.

В этой статье мы подробно и по шагам разберем, почему возникает эта проблема, как провести глубокую диагностику на стороне сервера приложений и СУБД MS SQL Server, и какие конкретные действия помогут навсегда устранить эти зависания.

Разберем причину: что на самом деле означает показатель «Захвачено СУБД»

Многие технические специалисты ошибочно полагают, что рост показателя «Захвачено СУБД» (в технологическом журнале и API он называется db-proc-took) свидетельствует исключительно о транзакционных блокировках. На самом деле этот счетчик работает шире: он фиксирует время непрерывного удержания физического соединения с СУБД рабочим процессом 1С для конкретного сеанса.

Бесконечный рост этого показателя может быть вызван тремя основными причинами:

1. Классическая транзакционная блокировка: СУБД выполняет «тяжелый» запрос или ожидает освобождения заблокированных ресурсов другим сеансом.
2. Удержание менеджера временных таблиц: Если в нетиповом коде (например, в отчете или обработке проведения) создается объект МенеджерВременныхТаблиц, и ссылка на него помещается в долгоживущую переменную (переменную модуля формы, модуля объекта или в параметры сеанса), то физическое соединение с SQL-сервером не разовьется до тех пор, пока этот объект не будет уничтожен. Пул соединений сервера 1С истощается, и база начинает «вешаться».
3. Зависание рабочего процесса rphost: Процесс отправляет запрос к СУБД, но из-за внутренней ошибки платформы, нехватки памяти или сбоя сетевого стека теряет контроль над ним, оставляя транзакцию открытой «навсегда».

Шаг 1. Очистка сеансового кэша при зависании консоли кластера 1С

Автор темы столкнулся с характерным симптомом: «При попытке удалить пользователя зависает консоль кластера». Это происходит из-за повреждения или взаимной блокировки файлов сеансовых данных, которые сервер 1С хранит на диске. Обычная очистка пользовательского кэша здесь бесполезна. Нам необходимо принудительно очистить сеансовый кэш службы.

Выполним процедуру очистки по шагам:

1. Откроем оснастку управления службами Windows (services.msc) или консоль Linux и остановим службу «Агент сервера 1С:Предприятия».
2. Перейдем в каталог хранения служебных файлов сервера приложений. По умолчанию в Windows это путь:
   C:\Program Files\1cv8\srvinfo\ (или C:\Program Files (x86)\1cv8\srvinfo\ для 32-разрядной службы).
3. Зайдем в папку вашего кластера. Обычно она называется reg_1541.
4. Найдем в этой папке каталог, название которого начинается на snccntx (например, snccntx5e9a4d...). Именно здесь хранятся кэшированные данные активных сеансов в формате файлов *.dat. При аварийных завершениях процессов эти файлы могут повреждаться, вызывая зависание консоли при попытке считать информацию о сеансах.
5. Полностью удалим папку snccntx. Не беспокойтесь, сервер 1С автоматически пересоздаст ее при следующем запуске.
6. Запустим службу Агента сервера 1С. Консоль администрирования снова станет отзывчивой, а «фантомные» мертвые сеансы исчезнут.

Шаг 2. Оперативная диагностика и снятие блокировки через MS SQL Server

Когда система зависла, а перезапускать сервер приложений 1С нельзя (поскольку в других базах работают пользователи), мы можем решить проблему точечно со стороны СУБД. Нам необходимо найти транзакцию, которая выступает «главным блокировщиком» (Head Blocker), и принудительно завершить ее.

Для этого откроем SQL Server Management Studio (SSMS) и выполним следующий диагностический запрос к системным представлениям:

SELECT 
    er.blocking_session_id AS [ID блокировщика],
    er.session_id AS [Заблокированный ID],
    es.program_name AS [Приложение 1С],
    es.login_name AS [Пользователь SQL],
    er.wait_time AS [Время ожидания (мс)],
    er.wait_type AS [Тип ожидания],
    est.text AS [Текст SQL-запроса]
FROM sys.dm_exec_requests er
JOIN sys.dm_exec_sessions es ON er.session_id = es.session_id
CROSS APPLY sys.dm_exec_sql_text(er.sql_handle) est
WHERE er.blocking_session_id <> 0;

Проанализируем результат выполнения этого запроса. В колонке [ID блокировщика] мы увидим идентификатор системного процесса (SPID), который держит блокировку и не дает работать остальным. Выяснив этот ID (например, 74), мы можем мгновенно убить его на уровне СУБД с помощью команды:

KILL 74;

Это приведет к немедленному откату зависшей транзакции в MS SQL. При этом рабочий процесс сервера 1С перенаправит пострадавшего пользователя на новое соединение, выдав ему ошибку о разрыве связи, но вся остальная база продолжит работу в штатном режиме без перезапуска службы Агента.

Шаг 3. Устранение сетевых микроразрывов (Настройка TCP Keep-Alive)

Очень часто мертвые сеансы с растущим показателем «Захвачено СУБД» возникают из-за нестабильной работы сети (особенно если пользователи работают через Wi-Fi, VPN или тонкие клиенты). При кратковременной потере пакетов клиентское приложение 1С закрывается, но сервер 1С не получает сетевой пакет об отключении (FIN). Сервер продолжает считать сеанс активным, удерживая все блокировки в SQL.

Чтобы операционная система сервера своевременно определяла «обрыв» таких зависших соединений, настроим параметры TCP Keep-Alive в реестре Windows на серверах приложений и СУБД:

1. Откроем редактор реестра (regedit).
2. Перейдем по пути:
   HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
3. Создадим (или изменим) следующие параметры типа DWORD (32-бит):
   • KeepAliveTime — установим значение 300000 (в десятичной системе). Это заставит ОС проверять активность простаивающего соединения каждые 5 минут (вместо стандартных 2 часов).
   • KeepAliveInterval — установим значение 1000 (в десятичной системе). Это интервал между повторными проверками, если ответ на первый запрос активности не был получен.
4. Перезагрузим сервер для применения изменений в сетевом стеке.

Шаг 4. Устранение ограничений 32-разрядного сервера 1С и утечек памяти

В обсуждении на форуме упоминается, что у автора используется 32-разрядный сервер приложений 1С. Это критическое «узкое горлышко» для современных баз данных. Архитектура 32-битных систем накладывает жесткое ограничение: один рабочий процесс rphost не может адресовать более 4 ГБ оперативной памяти (на практике зависания и падения из-за фрагментации памяти начинаются уже при достижении процессом 3-3.2 ГБ).

Когда пользователь запускает тяжелый отчет или групповую обработку, рабочий процесс rphost пытается обработать эти данные. Память процесса мгновенно упирается в лимит, он впадает в состояние бесконечного свопинга или утечки памяти, зависает сам и «вешает» соединение с СУБД, вызывая бесконечный рост «Захвачено СУБД».

Рекомендации по устранению лимитов памяти:

1. Переход на 64-разрядный сервер: Это единственное стратегически верное решение. 64-разрядная версия сервера приложений 1С не имеет ограничений в 4 ГБ на процесс и позволяет задействовать весь объем физической памяти сервера.
2. Ограничение расхода памяти на сервере 1С: Если возможности быстро перейти на х64 нет, настройте перезапуск рабочих процессов в консоли кластера 1С. Установите параметры перезапуска рабочих процессов:
   • Допустимый объем памяти — например, 3000000 КБ (около 3 ГБ).
   • Интервал превышения допустимого объема памяти — 300 секунд. Это позволит серверу безопасно и автоматически заменять «раздувшиеся» процессы новыми без прерывания работы пользователей.

Шаг 5. Оптимизация настроек MS SQL Server: tempdb и авторасширение

Иногда зависание происходит на стороне СУБД в момент, когда база данных или служебная база tempdb исчерпывают свободное место и пытаются расширить свои файлы на диске. Рассмотрим этот процесс подробнее.

Если в настройках авторасширения (Autogrowth) базы данных установлен слишком маленький шаг (например, по умолчанию 1 МБ) или, наоборот, слишком большой в процентах (например, 10%), СУБД во время записи данных останавливает все транзакции (что вызывает зависание сеансов 1С и рост времени захвата СУБД) для проведения физического выделения места на диске. Если диск медленный, эта процедура может занимать десятки секунд, парализуя работу пользователей.

Настроим базу данных правильно:

1. Откроем свойства вашей рабочей базы данных в SSMS и перейдем в раздел Files (Файлы).
2. Для файла данных (.mdf) установим фиксированный шаг авторасширения (Autogrowth) в мегабайтах (например, 512 MB или 1024 MB вместо процентов).
3. Для файла лога транзакций (.ldf) установим авторасширение в размере 256 MB или 512 MB.
4. Проделаем аналогичные настройки для системной базы данных tempdb, так как 1С активно использует временные таблицы СУБД при построении сложных запросов. Выделим под tempdb несколько файлов данных одинакового размера (по количеству ядер процессора, но не более 8) с фиксированным авторасширением в 256 MB.

Шаг 6. Исправление ошибок платформы и проведение реструктуризации таблиц

В теме указана версия платформы 8.3.6.2449. Это старый релиз, содержащий известный баг: при определенных условиях во время аварийного прерывания транзакции рабочий процесс rphost мог «забыть» отправить команду ROLLBACK TRANSACTION в SQL Server. В итоге транзакция «зависала» в СУБД в открытом состоянии навсегда.

Дополнительно ситуацию ухудшают так называемые «демонические» обновления конфигурации (динамическое обновление без выгона пользователей), которые часто приводят к рассинхронизации структуры метаданных и физических таблиц SQL.

Для исправления структуры таблиц и очистки от накопленных ошибок выполним реструктуризацию базы данных:

1. Запустим базу данных в режиме Конфигуратора.
2. Создадим новый пустой объект метаданных (например, создадим пустую обработку с именем ВременнаяОбработкаРеструктуризации).
3. Выполним обновление конфигурации базы данных (нажав клавишу F7). В этот момент платформа проверит соответствие метаданных физическим таблицам СУБД.
4. Удалим только что созданную пустую обработку.
5. Снова запустим обновление конфигурации базы данных (F7). Данный прием инициирует принудительную реструктуризацию и обновление индексов основных таблиц, исправляя возможные логические несоответствия СУБД.
6. Проведем полное Тестирование и исправление (ТиИ) информационной базы в меню Администрирование -> Тестирование и исправление, выбрав пункты «Реиндексация таблиц» и «Пересчет итогов».

Проанализировав все описанные шаги и внедрив эти настройки, мы обеспечим отказоустойчивость серверов 1С и СУБД, исключим появление «зомби-сеансов», стабилизируем работу пользователей и избавимся от необходимости постоянного ручного перезапуска службы Агента.