Сервер 1С тормозит или не отвечает: служба, кластер, СУБД, ресурсы и сеть по порядку

Проверить работоспособность сервера 1С быстрее всего так: убедиться, что запущена служба агента (ragent), что сервер слушает порты 1540, 1541 и диапазон рабочих процессов 1560–1591, а затем выполнить rac cluster list и посмотреть список баз и сеансов. Если все три шага прошли, сервер жив, и дальше ищем узкое место: СУБД, ресурсы машины или сеть.

Ниже — порядок диагностики от простого к сложному. Он одинаков для Windows и Linux, различаются только команды. Каждая следующая проверка имеет смысл, только если предыдущая прошла успешно.

1. Первая проверка сервера 1С: служба агента и открытые порты

Сервер 1С:Предприятия 8.3 — это три вида процессов:

• 🟢 ragent — агент сервера, принимает первое подключение клиента на порту 1540;
• 🟢 rmngr — менеджер кластера, порт 1541;
• 🟢 rphost — рабочие процессы, в них выполняется код конфигурации; порты из диапазона, который задан в свойствах рабочего сервера (по умолчанию 1560–1591).

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

Windows

1. Откройте services.msc и найдите службу с именем вида 1C:Enterprise 8.3 Server Agent (x86-64). Состояние должно быть «Выполняется», тип запуска — «Автоматически».
2. В Диспетчере задач на вкладке «Подробности» проверьте, что есть процессы ragent.exe, rmngr.exe и хотя бы один rphost.exe.
3. Проверьте, что порты действительно слушаются:

netstat -ano | findstr ":1540 :1541 :156"

В выводе должны быть строки со статусом LISTENING. Последний столбец — PID процесса, его можно сверить с Диспетчером задач.

То же через PowerShell:

Get-Service -DisplayName "1C:Enterprise*"
Get-Process ragent, rmngr, rphost -ErrorAction SilentlyContinue | Select-Object Name, Id, WS

Linux

Имя юнита зависит от версии платформы и способа установки, поэтому сначала найдите его:

systemctl list-units --all | grep -i 1c
systemctl status <имя_юнита>
ss -tlnp | grep -E ':15(40|41|6[0-9]|[7-8][0-9]|9[01])'
ps -eo pid,rss,cmd | grep -E 'ragent|rmngr|rphost' | grep -v grep

Служба не стартует вовсе — сразу переходите к журналу событий (раздел 2). Частые причины: занят порт 1540 другим экземпляром агента, у учётной записи службы (обычно USR1CV8) нет прав на каталог srvinfo, кончилось место на диске.

2. Где искать ошибки: журналы сервера 1С и технологический журнал

Логов у сервера 1С несколько, и у каждого своя задача.

Журнал регистрации удобнее смотреть не в файлах, а из самой базы: Администрирование → Обслуживание → Журнал регистрации в типовых конфигурациях на «Такси», либо из Конфигуратора. Отфильтруйте по уровню «Ошибка» за нужный интервал.

Как включить технологический журнал

Технологический журнал по умолчанию выключен. Он включается файлом logcfg.xml в каталоге conf платформы (в Windows обычно C:\Program Files\1cv8\conf\). Платформа перечитывает файл сама, перезапуск службы не нужен — изменения подхватываются примерно за минуту.

Минимальная настройка «только исключения и аварийные завершения»:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1C_TechLog\errors" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <event>
      <eq property="name" value="PROC"/>
    </event>
    <property name="all"/>
  </log>
</config>

• EXCP — исключительные ситуации, в том числе ошибки, которые видят пользователи;
• PROC — события процессов сервера: запуск, остановка, аварийное завершение;
• history="24" — хранить файлы за 24 часа, старые удаляются автоматически.

💡 Каталог для журнала создайте заранее и дайте учётной записи службы 1С права на запись. Если прав нет, журнал молча не пишется.

3. Диагностика кластера серверов 1С: консоль и rac

Когда служба работает, проверяем сам кластер: видит ли он рабочий сервер, подняты ли процессы, сколько сеансов и сколько памяти они занимают.

Консоль администрирования серверов

Это оснастка MMC, ставится вместе с компонентом «Администрирование сервера 1С:Предприятия». Если оснастка открывается с ошибкой, зарегистрируйте библиотеку той версии платформы, которой управляете (командная строка от имени администратора):

regsvr32 "C:\Program Files\1cv8\8.3.xx.xxxx\bin\radmin.dll"

Номер версии подставьте свой. Версия консоли должна совпадать с версией сервера.

В консоли посмотрите по веткам:

1. «Рабочие серверы» — сервер присутствует, в свойствах указан правильный диапазон портов.
2. «Рабочие процессы» — у каждого процесса состояние «Включён», видна занимаемая память и показатель «Доступная производительность». Резкое падение доступной производительности у одного процесса — первый признак его перегрузки.
3. «Информационные базы» — нужная база есть в списке.
4. «Сеансы» и «Соединения» — нет ли «зависших» сеансов, которые висят часами.
5. «Блокировки» — какие объекты сейчас заблокированы и кем.

Утилита rac (Windows и Linux)

Для rac нужен запущенный сервер администрирования ras. Запустить его вручную:

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\ras.exe" cluster --port=1545 localhost:1540

Дальше в другом окне:

rac localhost:1545 cluster list
rac localhost:1545 server list --cluster=<uuid_кластера>
rac localhost:1545 process list --cluster=<uuid_кластера>
rac localhost:1545 infobase summary list --cluster=<uuid_кластера>
rac localhost:1545 session list --cluster=<uuid_кластера>

Идентификатор кластера берётся из вывода первой команды. Если на кластере заданы администраторы, добавьте --cluster-user и --cluster-pwd. Полный список параметров — rac help и rac help <режим>.

💡 Команда rac cluster list — лучший «пульс» сервера. Если она отвечает, агент и сервер администрирования живы. Если висит или выдаёт ошибку соединения — проблема на уровне служб, а не баз.

4. Проверка связи сервера 1С с СУБД

Пользователь видит «1С висит», а причина часто в СУБД: она недоступна, перегружена или держит блокировку. Подключение к СУБД делает рабочий процесс 1С, поэтому проверяйте связь с самого сервера 1С, а не со своего компьютера.

Параметры подключения (сервер СУБД, имя базы, пользователь) смотрите в свойствах информационной базы в консоли кластера.

MS SQL Server

sqlcmd -S SQLSRV01 -U sa -Q "SELECT @@VERSION"
powershell Test-NetConnection SQLSRV01 -Port 1433

Кто кого блокирует прямо сейчас:

SELECT session_id, blocking_session_id, wait_type, wait_time, status
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

PostgreSQL

psql -h pgsrv01 -U postgres -c "select version();"
psql -h pgsrv01 -U postgres -d base1c -c "select pid, state, wait_event_type, now()-query_start as dur from pg_stat_activity where state <> 'idle' order by dur desc;"

Что ещё проверить на стороне СУБД:

• 📌 свободное место на дисках с данными и журналом транзакций;
• 📌 давно ли выполнялось обслуживание: обновление статистик и перестроение индексов (SQL Server), VACUUM/ANALYZE (PostgreSQL);
• 📌 не «съела» ли СУБД всю оперативную память машины, если 1С и СУБД стоят на одном сервере. Для SQL Server ограничьте max server memory, иначе рабочим процессам 1С не хватит памяти.

5. Нагрузка на сервер 1С: процессор, память, диск

Если кластер работает и СУБД отвечает, а всё медленно — смотрим ресурсы. Снимать показатели нужно в момент, когда пользователи жалуются, а не утром в пустом офисе.

Какие счётчики смотреть

Пороги ориентировочные: на NVMe-дисках нормальная задержка — единицы миллисекунд, и 20 мс там уже тревожный сигнал.

Память рабочих процессов

В консоли кластера в ветке «Рабочие процессы» видно, сколько памяти занимает каждый rphost. Если один процесс постоянно разрастается, проверьте настройки перезапуска в свойствах рабочего сервера: допустимый объём памяти рабочих процессов и интервал превышения. После превышения кластер сам переводит процесс в режим перезапуска: новые соединения уходят в другой процесс, старый завершается.

Место в srvinfo

Каталог srvinfo растёт из-за журналов регистрации и сеансовых данных. Когда диск под ним заполняется, сервер начинает выдавать странные ошибки, вплоть до отказа запускать рабочие процессы. Проверьте размер подкаталогов reg_1541 и найдите самые крупные.

6. Сеть между клиентами и сервером 1С

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

Проверка с компьютера пользователя:

Test-NetConnection srv1c -Port 1540
Test-NetConnection srv1c -Port 1541
Test-NetConnection srv1c -Port 1560
ping srv1c
nslookup srv1c

Главный приём, о котором часто забывают: клиент должен разрешать имя сервера ровно так, как сервер зарегистрирован в кластере. Агент возвращает клиенту адрес менеджера и рабочего процесса по имени из свойств рабочего сервера. Если там указано короткое имя SRV1C, а у клиента оно не разрешается (другой DNS-суффикс, VPN), первое подключение пройдёт, а следующее упадёт. Лечится записью в DNS или в файле C:\Windows\System32\drivers\etc\hosts на клиенте.

Что проверить в брандмауэре сервера:

• 🔓 входящие TCP 1540, 1541 и весь диапазон рабочих процессов (1560–1591 или ваш);
• 🔓 порт 1545, если администрируете кластер удалённо через rac;
• 🔓 порт СУБД (1433, 5432) только между сервером 1С и сервером СУБД, а не для всей сети.

7. Постоянный мониторинг сервера 1С вместо ручных проверок

Ручная диагностика отвечает на вопрос «что сломалось сейчас». Чтобы узнавать о проблеме раньше пользователей, нужен мониторинг.

Простейший сторож на PowerShell, который можно повесить в Планировщик заданий каждые 5 минут:

$svc = Get-Service -DisplayName "1C:Enterprise 8.3 Server Agent*"
$port = Test-NetConnection -ComputerName localhost -Port 1540 -WarningAction SilentlyContinue
if ($svc.Status -ne 'Running' -or -not $port.TcpTestSucceeded) {
    $msg = "{0} {1}: служба={2}, порт1540={3}" -f (Get-Date), $env:COMPUTERNAME, $svc.Status, $port.TcpTestSucceeded
    Add-Content -Path "D:\Monitor\1c_alert.log" -Value $msg
    # сюда же — отправка письма или сообщения в мессенджер
}

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

💡 Для Zabbix удобно опрашивать кластер через rac session list и rac process list и считать количество сеансов и память процессов. Так видно рост нагрузки за неделю, а не только факт падения.

8. Нагрузочный тест: как проверить сервер 1С до жалоб пользователей

Когда сервер новый, переезжает на другое железо или в виртуализацию, полезно измерить его производительность заранее.

1. Тест Гилёва (TPC-1C) — сторонняя бесплатная обработка. Запускается в тестовой базе на этом сервере и выдаёт оценку в условных единицах. Главное в ней — однопоточная производительность: именно она определяет, как быстро проводится один тяжёлый документ.
2. «Тест-центр» из 1С:КИП — имитирует работу многих пользователей по сценариям: ввод документов, отчёты. Показывает, при каком числе пользователей начинает расти время операций.
3. Свой контрольный замер — выберите 3–4 типовых операции (провести реализацию на 50 строк, сформировать ОСВ за год, закрыть месяц на копии) и засеките время. Повторяйте после каждого изменения железа или настроек.

Сравнивайте результаты только между собой, на одном и том же сервере до и после изменений. Абсолютная цифра теста без контекста мало что говорит.

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