Files

dttb d00d856513 projects: вынес Бужарово в отдельную папку buzharovo/

Server1C — это самостоятельный объект (организация в Бужарово), не часть
домашней инфраструктуры dttb. Переношу projects/dttb/server1c.md →
projects/buzharovo/server1c.md, добавляю README.md как точку входа,
обновляю обратные ссылки.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-07 10:05:44 +03:00

4.8 KiB

Raw Blame History

date, type, tags

date

type

Бужарово 1С сервер — rmngr-loop после грязного ребута: рецепт

Контекст

07.05.2026 утром локальные пользователи в Бужарово начали жаловаться на резкое замедление 1С. NetBird и удалённый доступ ни при чём — тормозило в локальной сети офиса.

Сервер: Server1C (Win 2012 R2, 100.70.75.103 / 185.13.47.2), 1С 8.3.27.1606, MSSQL.

Что нашли

Сегодня в 09:05 сервер ушёл в crash:

System / Kernel-Power Event 41 (Critical): "rebooted without cleanly shutting down — system stopped responding, crashed, or lost power"
System / EventLog 6008: "previous shutdown was unexpected"

После загрузки:

rmngr.exe (менеджер кластера 1С) держит ~1.7 ядра постоянно в idle (норма <2% одного ядра).
rphost, sqlservr, диски (avg sec/write 1.6 ms, queue 0.03), память (5/64 GB) — в норме.
rac.exe localhost:1540 cluster list → "ошибка соединения с сервером", exit -1 — admin-канал rmngr повис, кластером невозможно управлять извне.
netbird.exe параллельно жжёт 1.4 ядра — побочный reconnect-loop после crash, после ребута сам успокоился.

Что не помогло

Полный ребут сервера (через Restart-Computer) — НЕ решает проблему. На свежезагруженном сервере с uptime=37 секунд rmngr опять на 178% одного ядра. То есть проблема воспроизводится при каждом первом запуске агента после crash.

Что помогло

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

После рестарта службы (не сервера!):

Процесс	До рестарта	После рестарта
rmngr	178% ядра	3% ядра
rphost	19%	1%
ragent	0%	1%

Все клиенты в этот момент вылетают — нужно предупредить за 2-3 минуты. Перезаход штатный.

Побочный эффект

После рестарта остался орфан-процесс старого ragent от прошлого запуска (не слушает 1540, висит в памяти). Можно безопасно прибить:

Get-Process ragent | Where-Object { $_.Id -ne (Get-NetTCPConnection -LocalPort 1540).OwningProcess } | Stop-Process -Force

Корневая причина — открыта

Почему rmngr зацикливается после первого запуска ragent — точно не выяснено. Гипотезы:

Повреждённый кэш кластера C:\Program Files\1cv8\srvinfo\reg_*\ после crash.
Регресс в 8.3.27.1606 при восстановлении сеансов.
Disabled-служба RagentServer_8327 (старый дубликат) что-то мешает в реестре при первом старте.

Если повторится — смотреть C:\Program Files\1cv8\srvinfo\reg_*\1Cv8FTLog\ и 1Cv8Log на ошибки.

Что сделать долгосрочно

В кластере 1С сейчас один rphost на всех локальных пользователей — бутылочное горлышко. Через консоль администрирования сервера 1С увеличить количество рабочих процессов: 1 rphost на 8-12 сеансов. Это отдельная задача, не на горячую.

Команды диагностики (для повтора)

WinRM-сессия с Mac:

import winrm
s = winrm.Session('http://100.70.75.103:5985/wsman',
                  auth=('dttb','1qaz!QAZ'),
                  transport='basic')

Дельта CPU за 5 сек по процессам:

$names='rmngr','rphost','netbird','sqlservr','ragent'
$first=@{}; $last=@{}
Get-Process | ?{$names -contains $_.Name} | %{ $first[$_.Name]=$_.CPU }
Start-Sleep 5
Get-Process | ?{$names -contains $_.Name} | %{ $last[$_.Name]=$_.CPU }
foreach($n in $names){ "$n delta=$($last[$n]-$first[$n])s" }

Если у rmngr дельта >50 за 5 секунд — диагноз "rmngr-loop" подтверждён, делать рестарт службы.

См. также projects/buzharovo/server1c.

4.8 KiB Raw Blame History Unescape Escape