Кластер серверов 1С: рабочие процессы, память и почему сервис падает по ночам

«Утром всё работает, к вечеру виснет, ночью служба падает» — заявка, которую мы разбираем несколько раз в квартал. Почти всегда причина в трёх-четырёх параметрах кластера, оставленных по умолчанию. Разберём, что за ними стоит, какие значения мы ставим на практике и почему половина советов из интернета делает только хуже.

Даже на одиночном сервере 1С поднимает полноценный кластер. Это сбивает с толку: администратор ищет «настройки сервера», а находит дерево из серверов, менеджеров и процессов.

Действующих лиц три:

• ragent — агент сервера. Служба, которая стартует вместе с Windows и держит список кластеров. Слушает 1540. Если упал он — не работает ничего.
• rmngr — менеджер кластера. Ведёт список баз, сеансов, блокировок, журнал регистрации. Слушает 1541.
• rphost — рабочий процесс. Собственно исполняет код конфигурации. Их может быть много, каждый берёт свой порт из диапазона 1560–1591.

Практический вывод: когда пользователи говорят «1С отвалилась», сначала смотрим, что именно умерло. Падение rphost выкидывает часть сеансов, но база остаётся доступной. Падение rmngr роняет всех сразу. А если пропал ragent, консоль администрирования даже не подключится.

Get-Process ragent,rmngr,rphost -ErrorAction SilentlyContinue |
  Select-Object Name, Id, @{n='RAM_MB';e={[int]($_.WorkingSet64/1MB)}}, StartTime |
  Sort-Object RAM_MB -Descending

Эту команду мы вешаем на мониторинг: она показывает и факт жизни процессов, и сколько памяти каждый съел, и когда стартовал. Последняя колонка ценнее всего — по ней сразу видно, перезапускался ли процесс сам.

В свойствах кластера есть группа настроек памяти, и это место, где чаще всего ломают дрова.

Ключевое: порог без интервала не работает. Если оставить «интервал превышения» равным нулю, 1С не будет перезапускать процесс вообще — сколько бы он ни съел. Мы видели сервер, где заботливо выставили порог 4 ГБ, порадовались и ушли; через месяц rphost держал 11 ГБ, потому что интервал остался нулевым.

Обратная ошибка встречается не реже: порог ставят слишком низким — скажем, 2 ГБ на сервере, где формируется годовая оборотка. Процесс уходит на перезапуск прямо посреди отчёта, пользователь получает «Сеанс отсутствует или удалён», и заявка приходит уже про «1С выкидывает».

Как выбрать число честно: неделю снимаем WorkingSet64 по rphost раз в пять минут, берём 95-й перцентиль и добавляем 30 %. Это дольше, чем прочитать чужой совет, но результат держится годами.

Все числа выше бесполезны, если брать их из чужой статьи. Ниже — способ получить свои за семь дней и одну строчку планировщика.

Заводим задание, которое раз в 5 минут дописывает строку в CSV:

$out = "D:\1cv8\metrics\rphost.csv"
Get-Process rphost -ErrorAction SilentlyContinue | ForEach-Object {
  "{0};{1};{2}" -f (Get-Date -f "yyyy-MM-dd HH:mm"), $_.Id, [int]($_.WorkingSet64/1MB)
} | Add-Content $out

Через неделю в файле будет около 2000 строк на процесс. Считаем 95-й перцентиль:

$v = Import-Csv D:\1cv8\metrics\rphost.csv -Header t,pid,mb -Delimiter ';' |
     ForEach-Object { [int]$_.mb } | Sort-Object
$v[[int]($v.Count * 0.95)]

Полученное число плюс 30 % — это ваш «допустимый объём памяти». У клиента-оптовика на 34 рабочих местах вышло 2 870 МБ, порог поставили 3 800 МБ. За четырнадцать месяцев — ни одного внепланового перезапуска.

Что этот же файл даёт бесплатно: видно, в какие часы память растёт. Если пик приходится строго на 09:15 — это утренняя загрузка банковской выписки, а не «1С опять течёт». И лечится это уже не порогом, а разбором конкретной обработки.

Держать сбор постоянно не нужно. Неделя перед настройкой, неделя после — и файл можно архивировать до следующего раза.

Интервал перезапуска рабочих процессов — отдельный параметр, живущий на уровне кластера. Мы ставим 86400 секунд практически всегда.

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

Важная деталь, которую редко объясняют: перезапуск не выбрасывает пользователей. Процесс помечается «выключенным», новые соединения на него не идут, а существующие доживают до конца — на это и отводится параметр «выключенные процессы останавливать через». Если поставить там 0, вот тогда сеансы действительно оборвутся.

Проверить, что механизм реально отрабатывает, можно по времени старта процессов: наутро StartTime у rphost должен быть ночным. Если он недельной давности — перезапуск не настроен, что бы ни было написано в консоли.

Параметр «количество информационных баз на процесс» решает, будут ли базы делить один rphost.

Ноль означает «без ограничений» — все базы в одном процессе, пока хватает памяти. Экономно, но опасно: тяжёлый отчёт в торговой базе уводит в перезапуск и бухгалтерию. Единица даёт каждой базе свой процесс. Расход памяти вырастает, зато аварии перестают быть общими.

Наше правило: если на сервере больше одной боевой базы и они принадлежат разным подразделениям — ставим 1. Если база одна, параметр не имеет значения.

Второй параметр рядом — «количество соединений на процесс». Ставить его меньше 128 на современном железе смысла обычно нет; уменьшение плодит процессы, каждый из которых тянет свою копию служебных структур.

Отдельная история — менеджеры под каждый сервис. Галка выносит сервисы кластера (журнал регистрации, полнотекстовый поиск, блокировки, сеансовые данные) в отдельные процессы rmngr. На нагруженном сервере это полезно: тормозящий полнотекстовый поиск перестаёт задерживать работу с блокировками. На сервере до 30 пользователей выигрыш незаметен, а процессов становится больше. Включаем по факту проблемы, а не заранее.

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

Типичная картина у клиента на 30 мест. В 01:00 стартует полная реиндексация базы в MS SQL. В 01:00 же в 1С просыпается регламентное задание обмена с сайтом и выгрузка в бухгалтерию. В 01:30 подключается бэкап, который читает тот же том. Диск уходит в очередь, запросы 1С начинают ждать, rphost раздувается на ожиданиях, доходит до порога — и уходит в перезапуск прямо посреди обмена. Обмен падает, задание перезапускается, круг замыкается.

Разбирается это не подкруткой памяти, а расписанием. Мы разносим три окна:

• 00:30–01:30 — бэкап СУБД;
• 02:00–03:30 — обслуживание индексов и статистики;
• 04:00–05:00 — тяжёлые регламентные задания 1С.

И только после разведения окон смотрим на память. В восьми случаях из десяти трогать её уже не приходится.

Где смотреть подтверждение: журнал приложений Windows на предмет событий от источника 1C:Enterprise 8.3 Server Agent, плюс технологический журнал с фильтром по событиям EXCP и PROC. Второе показывает точный момент, когда процесс решил, что пора умирать.

Механизм позволяет сказать: «фоновые задания — только на второй сервер», «клиентские соединения — только на первый». Инструмент точный, и именно поэтому им легко всё сломать.

Две ошибки, которые мы разбирали у клиентов:

Первая — назначили требование «фоновые задания» на сервер, который потом вывели из кластера. Задания просто перестали выполняться. Молча. Никакой ошибки, просто нет подходящего процесса. Обнаружилось через две недели по непроведённым обменам.

Вторая — задали требование «не назначать» для клиентских соединений на всех серверах разом. Пользователи получили «Не найден рабочий процесс» и не могли зайти вообще.

Практическое правило: требования назначения функциональности имеют смысл начиная с двух физических серверов в кластере. На одиночном сервере они не дают ничего, кроме шанса выстрелить себе в ногу. Если всё-таки настраиваете — обязательно оставляйте хотя бы одно требование с типом «Назначать» и пустым значением объекта, как страховочную сеть.

• Интервал перезапуска рабочих процессов — 86400 с, время выключения процессов 60–120 с.
• Порог памяти рассчитан по замерам, интервал превышения ненулевой.
• Количество ИБ на процесс — 1, если боевых баз больше одной.
• Менеджеры под каждый сервис — только при подтверждённой проблеме с сервисами.
• Уровень отказоустойчивости выше 0 — только если серверов в кластере действительно несколько.
• Требования назначения функциональности не заданы, пока сервер один.
• Окна бэкапа, обслуживания СУБД и регламентных заданий разведены и не пересекаются.
• На мониторинге: живы ли ragent/rmngr/rphost, сколько памяти держат, когда стартовали.

Если после всего этого процесс всё равно упирается в порог за пару часов — проблема не в кластере, а в конкретном отчёте или обработке. Тогда идём в технологический журнал и ищем виновника поимённо.

И последнее. Кластер — не то место, где стоит экспериментировать вслепую на боевой базе в четверг вечером.

Мы за годы выработали простую дисциплину: один параметр за раз, замер до и замер после, запись в журнал изменений с датой и причиной. Звучит занудно, но именно эта дисциплина отличает ситуацию, когда через полгода вы точно знаете, почему порог памяти стоит на 3 800 МБ, от ситуации, когда никто уже не помнит, кто и зачем поставил там 1 024 и почему трогать страшно.

Меняйте по одному. Записывайте. Замеряйте.

Сколько rphost должно быть на сервере?

Столько, сколько получится из ваших ограничений по количеству баз и соединений на процесс. Прямого параметра «сделай N процессов» нет. На одиночном сервере с одной базой обычно живёт один-два rphost, и это нормально.

Перезапуск рабочих процессов выбрасывает пользователей?

Нет, если параметр «выключенные процессы останавливать через» не равен нулю. Процесс перестаёт принимать новые соединения, а действующие сеансы доживают штатно. Обрыв бывает как раз при нулевом значении.

Стоит ли включать менеджеры под каждый сервис?

На сервере до 30–40 пользователей выигрыш почти незаметен, а процессов становится больше. Включаем адресно, когда видим, что конкретный сервис — чаще полнотекстовый поиск или журнал регистрации — тормозит остальные.

Что делать, если rphost упирается в порог памяти за час?

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