Многие администраторы серверов 1С сталкиваются с ситуацией, когда после перезагрузки сервера служба 1С начинает вести себя нестабильно: процессы rphost циклически перезапускаются, потребление оперативной памяти достигает пика, а пользователи не могут войти в базы. Особенно остро эта проблема стоит на серверах с ограниченными ресурсами и большим количеством небольших информационных баз (например, множество типовых баз "1С:Бухгалтерия").
В этой статье мы подробно разберем ситуацию, когда "лавина" фоновых заданий при старте службы приводит к отказу в обслуживании, и рассмотрим методы стабилизации работы сервера 1С:Предприятие.
Давайте проанализируем, что происходит внутри сервера в момент старта. У нас есть сервер, на котором размещено порядка 30–50 информационных баз. Ресурсы ограничены (например, 24 ГБ ОЗУ), и на этом же сервере работает СУБД (MS SQL Server или PostgreSQL).
В штатном режиме работы задания запускаются по расписанию, распределенно во времени. Однако после простоя (остановки службы, перезагрузки сервера) происходит следующее:
rphost начинают стремительно потреблять оперативную память.rphost не отвечает или превысил лимиты, и принудительно завершает его, запуская новый.Первым делом мы должны понять, как распределяются ресурсы. В рассматриваемом случае SQL Server и сервер 1С находятся на одной машине. Это классическая схема для небольших внедрений, но она требует строгой дисциплины в настройках.
Если SQL Server настроен по умолчанию, он стремится захватить всю доступную свободную память. Когда серверу 1С требуется память для выполнения кода 1С (внутри rphost), ему приходится "бороться" за ресурсы. Если память заканчивается, начинаются тормоза из-за дискового ввода-вывода (swap) или краши процессов.
Рассмотрим базовую математику для 30–50 баз. Даже если базы пустые, запуск контекста регламентного задания требует загрузки метаданных конфигурации. Для современной "Бухгалтерии 3.0" это сотни мегабайт на сеанс. Умножьте это на 30 одновременных потоков — 24 ГБ ОЗУ могут закончиться за секунды.
Если увеличить физическую память прямо сейчас невозможно, нам необходимо дать системе "продышаться" и предотвратить принудительное убийство процессов менеджером кластера. Процесс может быть жив и работать (хоть и медленно из-за нагрузки на диск), но кластер считает его зависшим и убивает, начиная всё сначала.
Рассмотрим параметр кластера "Интервал перезапуска рабочих процессов" (или настройки контроля зависших процессов).
Что нужно сделать:
Почему это помогает: При старте системы и массовом запуске заданий нагрузка на диск (IOPS) возрастает колоссально. Процессы rphost работают медленно. Увеличивая интервал, мы говорим кластеру: "Не убивай процесс, даже если он тупит, дай ему время закончить инициализацию". Это позволяет заданиям выполниться (пусть и за 15 минут), после чего нагрузка спадает, и сервер входит в штатный режим.
Критически важно жестко ограничить память, доступную для СУБД, чтобы оставить гарантированный объем для процессов rphost.
Для MS SQL Server выполним следующие действия в Management Studio:
Как рассчитать: Если у вас всего 24 ГБ, отдайте системе 4 ГБ, SQL Server — 8–10 ГБ, а остальное (10–12 ГБ) оставьте серверу 1С. Если вы не ограничите SQL, он может занять 20 ГБ, и при запуске 1С произойдет коллапс.
В типовых конфигурациях (особенно БП 3.0, ЗУП 3.1) существует множество заданий, которые включены по умолчанию, но могут быть не нужны в конкретной базе.
Что следует отключить в первую очередь:
Рассмотрим, как отключить задания не входя в каждую базу (если баз много). К сожалению, штатно это делается внутри базы в режиме "1С:Предприятие" (Администрирование -> Обслуживание -> Регламентные операции). Однако, можно использовать внешние обработки для группового управления или скрипты.
Поскольку в нашем случае SQL Server и 1С:Предприятие установлены на одном физическом сервере, мы обязаны использовать протокол Shared Memory. Это исключает лишние накладные расходы на сетевой стек (TCP/IP через localhost) и копирование данных в памяти.
Как проверить и включить:
(local)), без указания порта или IP-адреса, чтобы клиент SQL (используемый сервером 1С) мог выбрать Shared Memory автоматически.Если проблема не уходит, существует радикальный, но действенный метод — запрет выполнения регламентных заданий на уровне свойств информационной базы в консоли кластера.
В свойствах каждой ИБ есть галочка "Блокировка регламентных заданий включена". Если она установлена, планировщик вообще не будет пытаться запускать задания.
Алгоритм действий для стабильного старта ("Ручной режим"):
Давайте рассмотрим пример кода на языке 1С (или VBS/PowerShell через COM), который может автоматизировать управление блокировкой, чтобы не "прокликивать" 30 баз вручную. Ниже пример логики скрипта, который можно адаптировать:
// Примерный алгоритм для административной обработки
СоединениеСАгентом = Новый COMОбъект("V83.COMConnector");
СоединениеСАгентом = СоединениеСАгентом.ConnectAgent("НашСервер");
Кластеры = СоединениеСАгентом.GetClusters();
Для Каждого Кластер Из Кластеры Цикл
СоединениеСАгентом.Authenticate(Кластер, "Администратор", "Пароль");
Базы = СоединениеСАгентом.GetInfoBases(Кластер);
Для Каждого База Из Базы Цикл
// Включаем блокировку, чтобы предотвратить автозапуск при рестарте
База.ScheduledJobsDenied = Истина;
СоединениеСАгентом.UpdateInfoBase(База);
КонецЦикла;
КонецЦикла;
Ситуация, описанная автором, типична для "уплотнения" серверов. Главная причина — конкуренция за память и агрессивное поведение планировщика заданий при старте.
Итоговый чек-лист действий:
Max Server Memory.Также стоит помнить, что версии платформы 1С регулярно обновляются. В некоторых релизах могут присутствовать ошибки утечки памяти (Memory Leaks). Если вышеописанные меры не помогают, имеет смысл протестировать работу на другой версии платформы (более новой или, наоборот, более стабильной LTS-версии).