Перезапуск кластера серверов 1С:Предприятия 8.3 в Windows и Linux

Чтобы перезапустить кластер серверов 1С, перезапускают службу агента сервера: в Windows это служба 1C:Enterprise 8.3 Server Agent (x86-64), в Linux — юнит srv1cv8… в systemd. Вместе с агентом (ragent) останавливаются менеджер кластера (rmngr) и все рабочие процессы (rphost), а при старте поднимаются заново.

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

Как устроен кластер и что именно перезапускается

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

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

Что важно для перезапуска:

• 🔹 служба в системе одна — служба агента. Остальные процессы — её дочерние;
• 🔹 данные баз хранит СУБД (MS SQL, PostgreSQL). Перезапуск кластера 1С СУБД не трогает, и перезапускать её вместе с 1С обычно не нужно;
• 🔹 реестр кластера и кэш сеансов лежат в каталоге srvinfo. В Windows по умолчанию это C:\Program Files\1cv8\srvinfo\, внутри — папка reg_1541 (по номеру порта менеджера);
• 🔹 если на машине несколько кластеров на разных портах (например, 1540 и 2540), у каждого своя служба и свой каталог reg_….

Подготовка: как перезапустить сервер 1С, не оборвав работу людей

При остановке службы агента все сеансы обрываются мгновенно. Документ, который бухгалтер не успел записать, пропадёт. Фоновое задание обмена прервётся на середине. Поэтому днём кластер перезапускают только в аварии, а плановые перезапуски — вечером или ночью.

Порядок подготовки:

1. Предупредите пользователей: письмо, сообщение в мессенджере, за 10–15 минут.
2. Установите блокировку начала сеансов для каждой информационной базы. В консоли кластера это свойства базы → флажок Блокировка начала сеансов включена с текстом сообщения и временем действия. Новые люди не зайдут, а у работающих есть время сохраниться.
3. Через 10–15 минут посмотрите список сеансов в консоли. Оставшиеся завершите вручную: правой кнопкой по сеансу → Удалить.
4. Отключите регламентные задания, если они запускаются как раз в окно перезапуска (флажок Блокировка регламентных заданий включена в тех же свойствах базы).
5. Только после этого останавливайте службу.

После перезапуска не забудьте снять блокировку начала сеансов. Иначе утром придут звонки «не пускает в базу», и сообщение будет вашим же текстом.

Перезапуск службы 1С в Windows

Через оснастку «Службы»

1. Нажмите Win+R, введите services.msc.
2. Найдите службу Агент сервера 1С:Предприятия 8.3 (x86-64) — так её отображаемое имя выглядит в русской Windows.
3. Правой кнопкой → Перезапустить. Либо Остановить, дождаться статуса «Остановлена», затем Запустить.

Второй вариант надёжнее: между остановкой и запуском можно проверить, что процессы действительно завершились.

Из командной строки

Командная строка, запущенная от имени администратора. Сначала уточните точное имя службы — оно зависит от разрядности и способа установки:

sc query state= all | findstr /i "1C:Enterprise"

Затем остановка и запуск:

net stop "1C:Enterprise 8.3 Server Agent (x86-64)"
net start "1C:Enterprise 8.3 Server Agent (x86-64)"

PowerShell-вариант одной строкой:

Restart-Service -Name "1C:Enterprise 8.3 Server Agent (x86-64)" -Force

Если rphost не завершился

Бывает, что служба уже «Остановлена», а в диспетчере задач висит rphost.exe и держит гигабайты памяти. Пока он жив, новый запуск может упереться в занятые порты.

Проверка:

tasklist /fi "imagename eq rphost.exe"
tasklist /fi "imagename eq rmngr.exe"

Если процессы остались — завершите их принудительно и только потом запускайте службу:

taskkill /f /im rphost.exe
taskkill /f /im rmngr.exe
taskkill /f /im ragent.exe
net start "1C:Enterprise 8.3 Server Agent (x86-64)"

Перезапуск с очисткой кэша сеансов

Классический приём, когда после обычного перезапуска остаются «призрачные» сеансы, ошибки соединения с рабочим процессом или кластер тормозит без видимой причины. Чистится кэш данных сеансов, а не реестр кластера.

1. Остановите службу агента и убедитесь, что rphost, rmngr и ragent завершились.
2. Откройте C:\Program Files\1cv8\srvinfo\reg_1541\.
3. Удалите (лучше сначала переместите в резервную папку) каталоги, имя которых начинается с snccntx.
4. Запустите службу.

Файл 1CV8Clst.lst не удаляйте. Это реестр кластера: список баз, рабочих серверов, администраторов. Без него кластер поднимется пустым, и базы придётся регистрировать заново. Перед любыми действиями в srvinfo сделайте копию всего каталога.

Перезапуск сервера 1С на Linux

На Linux сервер 1С работает как служба systemd (в старых установках — как скрипт init.d). Имя юнита зависит от версии платформы, поэтому начинайте с поиска:

systemctl list-units --all | grep -i srv1cv8

Типичные варианты:

• 🐧 srv1cv83 — старые установки, один сервер на машине;
• 🐧 srv1cv8-8.3.24.1342@default — новые версии платформы: имя содержит номер версии, а после @ — имя экземпляра.

Перезапуск и проверка состояния:

sudo systemctl restart srv1cv8-8.3.24.1342@default
sudo systemctl status srv1cv8-8.3.24.1342@default

Подставьте своё имя юнита из вывода первой команды. В старых установках с init.d работает sudo /etc/init.d/srv1cv83 restart.

Проверить, что процессы перезапустились, а не остались висеть старые:

ps -eo pid,user,lstart,rss,cmd | grep -E 'ragent|rmngr|rphost' | grep -v grep

Колонка lstart покажет время запуска: у свежих процессов оно должно совпадать с моментом перезапуска. Если остался старый rphost, после systemctl stop завершите его через sudo kill <PID>, а при отказе — sudo kill -9 <PID>.

Кэш сеансов в Linux лежит в домашнем каталоге пользователя службы, по умолчанию /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/. Правило то же: при остановленной службе убрать каталоги snccntx*, а 1CV8Clst.lst оставить на месте.

Управление кластером из командной строки: ras и rac

Утилита rac управляет кластером без графической консоли: удобно для скриптов и для Linux, где MMC-оснастки нет. Работает она не напрямую, а через сервер администрирования ras, который нужно запустить заранее.

Запуск ras вручную (порт по умолчанию 1545):

./ras cluster --daemon

В Windows ras обычно регистрируют отдельной службой, чтобы он поднимался с системой:

sc create "1C:Enterprise 8.3 Remote Server" binPath= "\"C:\Program Files\1cv8\8.3.24.1342\bin\ras.exe\" cluster --service --port=1545 localhost:1540" DisplayName= "Сервер администрирования 1С" start= auto

Номер версии в пути замените на свой.

Основные команды rac, которые пригодятся при перезапуске:

# список кластеров и их идентификаторы
rac cluster list

# рабочие процессы: занятая память, число соединений
rac process list --cluster=<uuid-кластера>

# активные сеансы
rac session list --cluster=<uuid-кластера>

# завершить конкретный сеанс
rac session terminate --cluster=<uuid-кластера> --session=<uuid-сеанса>

Если на кластере заведены администраторы, к каждой команде добавьте --cluster-user и --cluster-pwd.

Блокировка входа в базу перед перезапуском:

rac infobase update --cluster=<uuid-кластера> --infobase=<uuid-базы> \
  --infobase-user=Администратор --infobase-pwd=*** \
  --sessions-deny=on --denied-message="Плановый перезапуск сервера 1С"

Снять блокировку — та же команда с --sessions-deny=off. Полный список параметров для вашей версии выводит rac help и rac help infobase.

Почему кластер 1С приходится перезапускать часто

Один перезапуск в месяц — норма. Ежедневные перезапуски «потому что иначе всё встаёт» — симптом, который надо разбирать.

Технологический журнал и дампы

Чтобы видеть ошибки платформы, создайте файл logcfg.xml в каталоге conf платформы (в Windows обычно C:\Program Files\1cv8\conf\). Минимальная настройка — исключения и дампы:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1C_TJ" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
  <dump create="true" location="D:\1C_dumps" type="3"/>
</config>

history="24" — хранить 24 часа. Журнал подхватывается без перезапуска службы через минуту-другую. Следите за диском: подробный журнал на нагруженном сервере легко занимает десятки гигабайт, поэтому событий для записи берите минимум и включайте только на время разбора.

Кроме журнала, смотрите:

• 📋 журнал событий Windows, раздел «Приложение» — ошибки службы агента и падения процессов;
• 📋 rac process list — какой процесс сколько памяти держит и сколько у него соединений;
• 📋 свободную оперативную память сервера: если её не хватает, систему душит своп, а не 1С.

Автоматический перезапуск служб и рабочих процессов

Цель — чтобы сбой поднимался сам, без звонка администратору в 7 утра.

Восстановление службы в Windows

В services.msc откройте свойства службы агента → вкладка Восстановление. Для первого, второго и последующих сбоев выберите Перезапуск службы, задержка — 1 минута.

То же самое командой:

sc failure "1C:Enterprise 8.3 Server Agent (x86-64)" reset= 86400 actions= restart/60000/restart/60000/restart/60000

reset= 86400 — счётчик сбоев обнуляется через сутки, 60000 — пауза минута перед повторным запуском.

Автоперезапуск в Linux

В systemd поведение задают через переопределение юнита, не трогая исходный файл:

sudo systemctl edit srv1cv8-8.3.24.1342@default

В открывшемся редакторе:

[Service]
Restart=on-failure
RestartSec=60

После сохранения выполните sudo systemctl daemon-reload. Теперь при аварийном падении служба поднимется через минуту, а штатная остановка через systemctl stop её не перезапустит.

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

В свойствах кластера в консоли есть параметры, которые снимают нагрузку с ночных перезапусков:

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

Ночной перезапуск по расписанию

Если без ежедневного перезапуска пока никак, вынесите его в планировщик заданий Windows или cron. Сценарий тот же, что вручную: блокировка баз через rac, ожидание, завершение сеансов, перезапуск службы, снятие блокировки. Время выбирайте так, чтобы оно не пересекалось с резервным копированием СУБД и ночными обменами.

Частые вопросы