Как устранить лавинообразный рост сеансов и конфликты блокировок в 1С после перехода на платформу 8.3.16?

Переход на новые версии платформы «1С:Предприятие 8.3» часто преподносит администраторам и разработчикам неожиданные сюрпризы. Типичный сценарий: конфигурация и код базы данных не менялись, количество активно работающих пользователей осталось прежним (например, около 55 человек), но сразу после обновления платформы (например, с версии 8.3.13.1644 на релиз 8.3.16.1063) в консоли кластера и списке активных пользователей фиксируется колоссальный рост сеансов — их число может лавинообразно вырасти до нескольких тысяч. Параллельно с этим пользователи начинают жаловаться на регулярные ошибки вида: «Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки».

В этой статье мы подробно разберем причины возникновения подобной аномалии, выясним связь между ростом фоновых процессов и транзакционными тупиками, а также рассмотрим пошаговый алгоритм устранения этой системной проблемы.

Выясняем причину: почему лавинообразно растет количество сеансов?

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

1. Интерактивный поиск «на лету» в динамических списках (при вводе текста в строку поиска списков документов, справочников или в обработках).
2. Формирование и вывод тяжелых отчетов, выполняемых во внешних или фоновых потоках.
3. Служебные фоновые задачи (индексация механизма полнотекстового поиска, сбор истории данных, регламентное обновление агрегатов и т.д.).

Каждое такое фоновое задание инициализирует создание нового служебного сеанса. В нормальных условиях эти сеансы мгновенно завершают свою работу, а их ресурсы возвращаются в так называемый пул сеансов кластера 1С для повторного использования последующими процессами. Однако в некоторых релизах платформы, в частности в крайне нестабильном релизе 8.3.16.1063, этот механизм работает некорректно.

Связь между ростом сеансов и конфликтами блокировок

Проанализируем детально, как зависание сеансов приводит к параличу работы всей информационной базы через механизм блокировок. В проблемных релизах платформы регулярно происходят аварийные завершения или зависания рабочих процессов rphost. Логика развития проблемы выглядит следующим образом:

1. Пользователь совершает действие (например, открывает форму списка документов с поиском), система порождает фоновое задание.
2. В процессе выполнения задания рабочий процесс rphost аварийно падает или зависает из-за внутренней ошибки платформы.
3. Поскольку фоновое задание не завершилось штатным образом, все наложенные им транзакционные блокировки (как СУБД, так и управляемые блокировки самой 1С) **не снимаются** и остаются активными в СУБД.
4. Платформа пытается запустить задачу повторно, создавая всё новые сеансы. Пользователь, не дождавшись ответа от интерфейса, нажимает кнопку поиска заново, генерируя новую волну фоновых задач.
5. Все новые сеансы моментально натыкаются на блокировки, оставленные «зависшим» или аварийно завершенным предшественником, и уходят в бесконечное ожидание до наступления таймаута (параметр TTIMEOUT). Возникает эффект «снежного кома»: тысячи мертвых сеансов удерживают таблицы СУБД, блокируя любую работу.

---

Пошаговый план решения проблемы

Для исправления ситуации нам потребуется комплексный подход — от обновления системного ПО до тонкой настройки параметров кластера серверов 1С и СУБД. Разберем каждый шаг подробно.

Шаг 1: Смена релиза платформы на стабильный

Релиз платформы 8.3.16.1063 признан экспертами и сообществом одним из наиболее подверженных утечкам памяти и падениям рабочих процессов. Простейшим и самым эффективным решением является переход на более стабильные, проверенные временем сборки. Мы настоятельно рекомендуем выполнить обновление до финальных релизов ветки 8.3.16 (например, 8.3.16.1814 и выше) либо выполнить полноценный переход на современные LTS-версии (такие как 8.3.18, 8.3.21 или актуальные стабильные релизы 8.3.22 / 8.3.24). В этих версиях механизмы очистки пула сеансов и обработки падения рабочих процессов были значительно доработаны.

Шаг 2: Настройка параметров спящих и пассивных сеансов в кластере

Чтобы оперативно избавляться от зависших фоновых процессов, которые удерживают транзакции, настроим автоматическое завершение неактивных сеансов через утилиту администрирования кластера серверов 1С:

1. Запустите консоль администрирования кластера серверов «1С:Предприятия».
2. Откройте свойства вашей информационной базы.
3. Установите параметр «Время засыпания пассивного сеанса» (например, 1200 секунд, что соответствует 20 минутам).
4. Установите параметр «Время завершения спящего сеанса» (рекомендуется выставить агрессивное значение — 120 секунд).

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

Шаг 3: Настройка обслуживания Полнотекстового поиска (ППД)

Регулярной причиной зависания фоновых транзакций при переходе на новые платформы становится повреждение индекса полнотекстового поиска. Проанализируем и исправим эту ситуацию:

1. Перейдите в интерфейсе вашей конфигурации в раздел Администрирование — Общие настройки — Полнотекстовый поиск данных.
2. Выполните очистку текущего индекса, нажав кнопку «Очистить индекс».
3. Запустите процесс повторного индексирования с помощью кнопки «Обновить индекс».
4. Если функционал полнотекстового поиска не критичен для ваших пользователей, рекомендуется временно полностью отключить его, сняв соответствующий флаг в настройках. Это сразу разгрузит сервер от лишних регламентных фоновых заданий.

Шаг 4: Настройка Технологического журнала для выявления узких мест

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

Создадим в каталоге установки платформы (по умолчанию для Windows это C:\Program Files\1cv8\conf\) файл конфигурации ТЖ с именем logcfg.xml следующего содержания:

Рассмотрим подробнее, за какими событиями мы будем следить с помощью этого лога:

• TTIMEOUT — регистрирует факты превышения времени ожидания блокировок. В теле этого события будет четко указано, какая именно строка кода 1С инициировала транзакцию, ушедшую в таймаут.
• TLOCK — фиксирует наложение управляемых блокировок 1С. Поможет выяснить, какой именно сеанс заблокировал ресурс и удерживал его в течение долгого времени.
• EXCP — зафиксирует системные исключения и падения рабочих процессов rphost, что укажет на аппаратные или платформенные сбои в момент возникновения блокировки.

Шаг 5: Анализ блокировок на стороне СУБД

Параллельно с анализом логов 1С необходимо отслеживать состояние транзакций непосредственно на стороне базы данных во время пиковых нагрузок.

Если мы работаем на СУБД MS SQL Server, то для оперативного обнаружения заблокированных процессов и ресурсов следует использовать системные динамические представления. Выполним следующий запрос в среде MS SQL Server Management Studio:

SELECT 
    r.session_id AS [ID сессии СУБД],
    r.blocking_session_id AS [Блокирующий сеанс (SPID)],
    r.wait_time AS [Время ожидания (мс)],
    t.text AS [Текст запроса SQL]
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.blocking_session_id <> 0;

Если в качестве СУБД используется PostgreSQL, мы можем проанализировать активные транзакции и выявить блокирующие идентификаторы процессов (PID) с помощью встроенного системного представления pg_stat_activity и функции pg_blocking_pids():

SELECT 
    pid AS "ID процесса",
    query AS "Выполняемый запрос",
    pg_blocking_pids(pid) AS "Кто заблокировал (PID)"
FROM pg_stat_activity 
WHERE cardinality(pg_blocking_pids(pid)) > 0;

Найденные «виновные» процессы на уровне СУБД можно завершить принудительно (командами KILL в MS SQL или pg_terminate_backend() в PostgreSQL), что позволит моментально «разжать» транзакционные тиски без полной перезагрузки сервера приложений 1С.

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