← На главную

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

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

Выясним причину зависания поиска в списках

Чтобы найти эффективное решение, детально проанализируем архитектуру платформы и факторы, приводящие к появлению «фантомных» фоновых заданий.

1. Особенности архитектуры платформы 1С: При вводе текста в строку поиска динамического списка система генерирует отдельное асинхронное ФоновоеЗадание. Это сделано специально, чтобы интерфейс основного сеанса пользователя не блокировался «намертво», пока сервер выполняет тяжелый запрос. Если пользователь продолжает вводить символы или закрывает форму, платформа отправляет команду на отмену текущего поиска. В журнале регистрации фиксируется событие отмены, но из-за недоработок в релизах веток 8.3.8, 8.3.9 и 8.3.10 это задание не всегда корректно уничтожается на стороне сервера 1С.
2. Тяжелые неоптимизированные запросы: Посмотрим на то, как формируются списки. Если динамический список строится по таблице с миллионами записей (например, большой справочник номенклатуры или журнал документов), и при этом отсутствуют подходящие индексы базы данных, поиск занимает аномально долгое время. Сервер не может быстро прервать выполнение такого SQL-запроса, что приводит к зависанию сеанса.
3. Сложные вычисляемые поля: Проблема усугубляется, если в динамический список выведены данные, требующие ресурсоемких расчетов "на лету" (например, актуальные остатки товаров, подсчет оборотов, соединение с виртуальными таблицами регистров).
4. Сбои полнотекстового поиска (ППД): Механизм поиска по строке в динамическом списке тесно интегрирован с полнотекстовым поиском платформы. Зависания часто происходят, если поиск совпадает по времени с выполнением регламентного задания ОбновлениеИндексаППД, либо если сам индекс поврежден.

Решение 1: Обновление платформы 1С:Предприятие

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

Ошибочное поведение массово наблюдается на релизах веток 8.3.8 и 8.3.9 (например, 8.3.8.1784 и 8.3.9.1850). Также проблема была замечена в некоторых релизах ветки 8.3.10, таких как 8.3.10.2252.

Для полного устранения бага разработчики 1С выпустили исправления. Проанализируем рекомендации: необходимо обновить сервер и клиенты до версии не ниже 8.3.10.2375 (или использовать более современные и стабильные ветки, такие как 8.3.17, 8.3.21 и выше, в зависимости от требований вашей конфигурации). Обновление платформы устраняет саму ошибку некорректного завершения потока при отмене поиска.

Решение 2: Обслуживание индекса полнотекстового поиска

Если прямо сейчас обновить платформу невозможно, рассмотрим административные меры обхода проблемы. Многим базам помогает полное перестроение индекса ППД.

1. Откроем в режиме Предприятия панель администрирования.
2. Перейдем в раздел Общие настройки -> Поиск данных.
3. Откроем форму Управление полнотекстовым поиском.
4. Нажмем кнопку Очистить индекс. Дождемся завершения операции.
5. После очистки нажмем Обновить индекс. Этот процесс может занять длительное время, поэтому рекомендуем выполнять его в нерабочие часы.

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

Решение 3: Безопасное удаление зависших сеансов на сервере 1С

Вместо грубого перезапуска службы веб-сервера (Apache или IIS), который прерывает работу вообще всех активных клиентов, применим более изящный метод очистки зависших заданий через консоль кластера серверов 1С. Для быстрого открытия необходимой оснастки можно использовать утилиту для запуска консоли кластера серверов 1С любых версий.

Разберем по шагам алгоритм "мягкой" перезагрузки рабочих процессов:

1. Запустим утилиту администрирования кластера серверов 1С.
2. Найдем в списке сеансов те, у которых в колонке "Приложение" указано ФоновоеЗадание, а время начала сильно отстает от текущего.
3. Посмотрим, какому именно рабочему процессу rphost принадлежат эти сеансы (запомним PID процесса).
4. Перейдем в раздел "Рабочие процессы" кластера.
5. Откроем свойства проблемного процесса rphost и установим признак Не использовать (выберем "Использование: Не использовать").
6. Применим изменения. Что произойдет дальше? Кластер 1С пометит этот процесс как неактивный для новых соединений. Все "живые" и работающие сеансы пользователей будут плавно переведены сервером на другие (или новые) рабочие процессы.
7. Подождем несколько минут. Когда в выключаемом процессе останутся только наши "мертвые" зависшие фоновые задания, мы можем безопасно завершить его.
8. Откроем диспетчер задач операционной системы на сервере и снимем задачу с процесса rphost.exe с нужным нам PID. Зависшие сеансы исчезнут, пользователи ничего не заметят.

Решение 4: Оптимизация работы и снижение нагрузки

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

• Сужение отборов: Порекомендуем пользователям сначала устанавливать быстрые отборы (например, жесткий период дат в журнале документов, отбор по конкретной организации или складу), и только после этого вводить текст в глобальную строку поиска. Чем меньше данных попадет в первичную выборку, тем быстрее отработает фоновое задание.
• Отказ от сложной сортировки: Попросим не использовать сортировку по связанным реквизитам и вычисляемым колонкам в огромных динамических списках перед вызовом поиска.

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

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