← На главную

Многие системные администраторы и специалисты по платформе 1С сталкиваются с пугающей ситуацией: в консоли кластера серверов волнообразно, буквально за одну секунду, запускается огромное количество (иногда более 200) сеансов с именем «Планировщик заданий». При этом базы данных начинают катастрофически «тормозить», а сами соединения в консоли выглядят пустыми — в полях подключения к информационной базе ничего не указано. Затем эти сеансы медленно, примерно по одному в секунду, начинают завершаться. Давайте вместе проанализируем ситуацию, выясним причину такого поведения сервера и разберем по шагам, как решить эту проблему.

Архитектурная природа «Планировщика заданий» в 1С

Для начала давайте выясним причину появления подобных коннектов. Важно понимать, что соединение «Планировщик заданий» — это не пользовательская сессия. Это внутреннее служебное соединение между менеджером кластера rmngr и рабочим процессом rphost. Оно отвечает за инициализацию фоновых задач и опрос рабочих процессов кластера.

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

Почему эти соединения пустые? Пустое поле информационной базы и номер соединения 0 — это штатное поведение для служебных процессов. Они принадлежат всему кластеру или конкретному rphost, а не конкретной клиентской базе данных. При этом количество базовых соединений планировщика обычно равно количеству активных баз, умноженному на количество рабочих процессов.

Причины лавинообразного роста соединений

Рассмотрим подробнее факторы, из-за которых количество служебных процессов начинает бесконтрольно расти:

1. Блокировки в СУБД (особенно при интеграциях). Если базы 1С активно обмениваются данными с внешними системами (например, средствами ADO) и во внешней базе возникает блокировка, 1С не может завершить операцию. В этот момент подошедшие по расписанию новые фоновые задания или новые попытки обмена начинают плодить новые задачи, так как предыдущие «зависли». Менеджер кластера открывает под них все новые и новые соединения планировщика.
2. Проблемы с сервером лицензирования. Иногда внешний сервер лицензирования перестает выдавать программные или аппаратные ключи. Внешние системы (например, веб-приложения), пытающиеся вычитать данные из 1С, получают ошибку авторизации. Из-за невозможности войти под клиентом кластер регистрирует их попытки в консоли в виде зависших «Планировщиков».
3. Поломка индексов полнотекстового поиска или журнала регистрации. В папках серверного кэша хранятся файлы полнотекстового поиска и ЖР. Если эти файлы повреждаются (например, после аварийной перезагрузки сервера), регламентные задания извлечения текста или слияния индексов начинают «падать» или зависать в бесконечном цикле, провоцируя появление новых процессов планировщика.
4. Внешние COM-соединения. Если внешняя система генерирует слишком много одновременных запросов, и платформа не успевает их закрывать, очередь зависших задач многократно возрастает.

Способы решения проблемы

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

Решение 1. Очистка серверного кэша и индексов полнотекстового поиска

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

1. Остановите службу сервера 1С:Предприятие (в службах Windows или Linux).
2. Дождитесь корректного завершения всех процессов, связанных с 1С (ragent, rmngr, rphost). Если какие-то процессы зависли в диспетчере задач — завершите их принудительно (Kill process).
3. Перейдите в каталог с серверными данными (по умолчанию это C:\Program Files\1cv8\srvinfo\reg_1541, где 1541 — порт кластера).
4. Внутри вы найдете папки с длинными буквенно-цифровыми названиями (GUID-ами баз). В них хранятся индексы полнотекстового поиска и журнал регистрации. Удалите (или переместите в резервный каталог) папки с GUID-ами. Обратите внимание: Сеансовые данные хранятся в папках, начинающихся на snccntx, их удаление часто не решает проблему, чистить нужно именно папки с GUID.
5. Перезапустите службу сервера 1С. При первом старте баз может наблюдаться задержка (будет происходить пересоздание файлов и индексов), но затем система начнет работать стабильно.

Решение 2. Ограничение количества соединений от внешних систем

Если проблема возникает в моменты пикового обмена с другими базами, посмотрим на пример жесткого лимитирования пула. Внешняя система может "бомбардировать" 1С запросами, не закрывая за собой сессии.

Вам необходимо на стороне внешней программы-инициатора установить ограничение (например, не более 5-10 активных соединений за один сеанс). Это даст возможность платформе 1С успевать обрабатывать запросы, корректно возвращать результат и закрывать процессы, не доводя до переполнения пула rphost.

Решение 3. Настройка регламентных заданий и сеансов

Чтобы избежать «снежного кома» из регламентных заданий при кратковременных блокировках СУБД, выполним следующие настройки на уровне кластера и информационной базы:

1. Откройте консоль администрирования кластера серверов 1С. Перейдите в свойства вашей информационной базы.
2. Настройте параметры управления сеансами. Задайте адекватные значения для полей Время засыпания пассивных сеансов и Время завершения спящих сеансов (например, завершать через 300 секунд). Это заставит сервер быстрее «убивать» соединения, которые потеряли отклик.
3. В самой конфигурации 1С (через внешнюю обработку «Консоль заданий» или стандартную панель регламентных заданий) проверьте расписания тяжелых операций (обмен данными, полнотекстовый поиск). Убедитесь, что интервалы запуска не слишком частые, или программно добавьте логику, которая блокирует запуск нового задания обмена, если предыдущее еще не завершено.

Решение 4. Диагностика сервера лицензирования

Если в консоли вы наблюдаете планировщики, а по факту это отвалившиеся веб-клиенты, проанализируем работу системы защиты. Перезапустите службу или менеджер лицензий (Aladdin HASP или службу программных лицензий). Убедитесь, что ключи доступны и нет сетевых потерь пакетов между кластером 1С и сервером лицензирования.

Подведем итоги: волнообразный рост пустых планировщиков задач — это защитная или побочная реакция менеджера кластера 1С на зависшие процессы или нехватку ресурсов (внешних блокировок БД, лицензий, сломанного кэша). Применяя комплексный подход (чистка GUID-папок, контроль внешних подключений и ревизия расписаний), вы сможете быстро вернуть серверу 1С былую производительность.