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.1 KiB

Raw Blame History

date, type, tags

date

type

Server1C — Сервер 1С в Бужарово

Подключение

Публичный IP: 185.13.47.2 (RDP:3389)
Netbird IP: 100.70.75.103 (server1c.netbird.cloud)
WinRM: порт 5985, basic auth
Учётка: dttb / 1qaz!QAZ
OS: Windows Server 2012 R2 (6.3.9600)
Hostname: Server1C
Локация: Бужарово

1С:Предприятие

Три службы агента:

1C:Enterprise 8.3 Server Agent — StartType: Automatic
1C:Enterprise 8.3 Server Agent (x86-64) — StartType: Automatic
RagentServer_8327 — версия 8.3.27.1606, StartType: Automatic

Решено: конфликт служб при загрузке (2026-04-16)

Проблема: 3 службы с Automatic стартовали одновременно, боролись за порты 1540/1541.

Служба 8.3.18 (x86) — бинарник удалён, падала с ошибкой "файл не найден"
RagentServer_8327 — дубликат без параметров, таймаут на портах
Рабочая: 1C:Enterprise 8.3 Server Agent (x86-64) (8.3.27.1606)

Решение: отключены лишние службы (Disabled), оставлена только x86-64.

Решено: rmngr-loop после грязного ребута (2026-05-07)

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

Диагноз:

Сервер ушёл в crash в 09:05 (Event 41 Kernel-Power: rebooted without cleanly shutting down + EventLog 6008: previous shutdown was unexpected).
После загрузки rmngr.exe (менеджер кластера 1С) держит ~1.7 ядра постоянно вместо штатных <2% в idle. rphost, sqlservr, диски, сеть — в норме.
rac.exe localhost:1540 cluster list отваливается с "ошибка соединения с сервером" — admin-канал rmngr повис, кластер не отвечает на управление.
netbird.exe параллельно крутит 1.4 ядра — это reconnect-loop как побочка crash, после ребута сам приходит в норму.

Рецепт:

Замерить дельту CPU через Get-Process | %{$_.CPU} за 5 секунд — если у rmngr >50% одного ядра в idle, диагноз подтверждён.
Полный ребут сервера НЕ помогает — после загрузки rmngr опять начинает жрать CPU. На свежезагруженном сервере uptime=0.6 min: rmngr уже на 178% ядра.
Помогает рестарт службы: Restart-Service -Name '1C:Enterprise 8.3 Server Agent (x86-64)' -Force. После рестарта rmngr возвращается к 3% ядра. Все активные сеансы пользователей вылетят — нужно их предупредить.
После рестарта может остаться орфан-процесс ragent от прошлого старта (не слушает 1540, висит). Прибить вручную: Stop-Process -Id <pid> -Force.

Why: причина рута rmngr-loop неясна — возможно повреждение кэша srvinfo, регресс 8.3.27.1606, или Disabled-служба RagentServer_8327 мешает первому запуску ragent. Если повторится — смотреть C:\Program Files\1cv8\srvinfo\reg_*\1Cv8FTLog\ на ошибки.

Долгосрочно: настроить несколько rphost в кластере (по одному на 8-12 сеансов) — сейчас один rphost на всех локальных юзеров = бутылочное горлышко.

4.1 KiB Raw Blame History Unescape Escape