Администрирование · 11 мин
Как проверить работу сервера 1С
Практическая инструкция по проверке работоспособности сервера 1С: службы агента, кластер, базы данных, сеть, журналы и типичные ошибки диагностики.
Проверка работы сервера 1С требуется в двух ситуациях: когда пользователи жалуются, что база «не открывается» или «тормозит», и как регулярная профилактика после обновления платформы, перезагрузки сервера или изменения сетевой инфраструктуры. В обоих случаях диагностику стоит вести последовательно — от физического уровня (сервер включён, сеть доступна) к прикладному (сеансы запускаются, запросы выполняются быстро).
Типовая клиент-серверная архитектура 1С состоит из трёх звеньев: агент сервера 1С (служба «Агент сервера 1С:Предприятия»), СУБД (чаще всего MS SQL Server или PostgreSQL) и клиентские приложения. Сбой может произойти на любом звене, и важная часть проверки — локализовать проблему, а не перезапускать всё подряд.
Ниже приведён порядок проверки, который подходит для Windows-развёртываний и в большинстве пунктов применим к Linux. Команды приведены для стандартных инструментов администрирования и не требуют установки дополнительного ПО.
Как проверить, что служба агента сервера 1С запущена
Первый шаг — убедиться, что на сервере работает процесс агента. В Windows откройте «Службы» (services.msc) и найдите службу с именем вида «Агент сервера 1С:Предприятия 8.3.x». Её состояние должно быть «Выполняется», а тип запуска — «Автоматически». Если служба остановлена, попробуйте запустить её и сразу проверьте журнал событий Windows: причина остановки почти всегда записывается туда.
Быстрая проверка из командной строки — поиск процесса ragent.exe:
tasklist | findstr ragentЕсли процесс найден, агент запущен. Дополнительно полезно проверить, что он «слушает» стандартные порты кластера: 1540 (агент), 1541 (менеджер кластера) и диапазон 1560–1591 (рабочие процессы rphost). Это делается командой:
netstat -ano | findstr ":1540 :1541 :156"Если служба не стартует, типичные причины — повреждённый каталог srvinfo (реестр кластера), недостаток прав у учётной записи службы, конфликт портов с другой версией платформы или антивирус, заблокировавший исполняемые файлы 1С. Прежде чем пересоздавать кластер, сделайте копию каталога srvinfo — там хранится список информационных баз и настройки.
Как проверить кластер через консоль администрирования
Консоль администрирования серверов 1С (оснастка «Администрирование серверов 1С Предприятия») показывает состояние кластера в целом. Откройте её, добавьте центральный сервер по имени или IP и разверните ветку кластера. Если консоль подключается и показывает рабочие процессы, агент и менеджер кластера работают.
Обратите внимание на разделы «Рабочие процессы» и «Сеансы». Рабочий процесс rphost должен присутствовать и потреблять разумный объём памяти. Если процессов нет либо они постоянно перезапускаются (растёт счётчик перезапусков, меняется PID), это признак аварийных завершений — смотрите технологический журнал и дампы.
В разделе «Информационные базы» проверьте, что нужные базы зарегистрированы и для них не включена блокировка соединений. Включённая блокировка — частая причина ситуации «сервер работает, а зайти нельзя»: пользователи получают сообщение о запрете подключения, хотя технически всё исправно.
Как проверить результат
Служба выполняется, ragent.exe в списке процессов
Служба остановлена или падает сразу после запуска
Порты 1540–1541 и диапазон 156x прослушиваются
Порты не отвечают или заняты другим приложением
rphost запущен, PID стабилен
Процессы исчезают или постоянно перезапускаются
Блокировка снята, сеансы создаются
Установлена блокировка, пользователи получают отказ
Как проверить связь сервера 1С с СУБД
Даже исправный кластер не даст пользователям работать, если нет соединения с сервером баз данных. Проверьте, что служба СУБД запущена (например, MSSQLSERVER для MS SQL) и что сервер 1С достигает её по сети: ping по имени и telnet на порт СУБД (по умолчанию 1433 для MS SQL, 5432 для PostgreSQL).
Далее убедитесь, что учётная запись, под которой сервер 1С обращается к СУБД, не заблокирована и её пароль не истёк. Смена пароля учётной записи SQL — классическая причина внезапного отказа после плановых работ ИТ-службы. Проверить подключение можно через SQL Server Management Studio или утилиту sqlcmd с теми же логином и паролем, что указаны в свойствах информационной базы.
Оцените также свободное место на дисках СУБД. Переполненный журнал транзакций или заполненный диск с файлами данных приводит к остановке базы с внешне загадочными ошибками со стороны 1С. Проверьте, что файлы данных и журнала имеют куда расти, а в MS SQL не сработало ограничение максимального размера файла.
Служба СУБД запущена? Открыт ли порт в файрволе?
Не истёк ли пароль, не заблокирован ли логин в СУБД
Состояние базы в СУБД, свободное место, журнал транзакций
Как проверить сетевую доступность сервера для клиентов
С рабочей станции пользователя проверьте разрешение имени сервера (nslookup имя_сервера) и доступность порта кластера. Клиент 1С соединяется с агентом по порту 1541, поэтому достаточно проверить его:
telnet имя_сервера 1541Если telnet не установлен, используйте PowerShell: Test-NetConnection имя_сервера -Port 1541. Успешный результат TcpTestSucceeded = True означает, что сеть и брандмауэр пропускают соединение. Если тест не проходит, проверяйте правила брандмауэра Windows на сервере и сетевые фильтры между сегментами.
Отдельная ловушка — имя сервера. Клиент получает от агента имя рабочего сервера и затем подключается к нему по этому имени. Если DNS у клиентов не разрешает короткое имя сервера, соединение обрывается уже после успешного обращения к агенту. Лечится настройкой DNS или записью в hosts, но правильнее привести разрешение имён в порядок централизованно.
Как проверить работоспособность через тестовый сеанс и журналы
Технические проверки завершайте прикладным тестом: запустите клиент 1С, войдите в базу под тестовой учётной записью и выполните типовые операции — откройте журнал документов, проведите документ, сформируйте отчёт. Это подтверждает, что вся цепочка «клиент — кластер — СУБД» работает, а не только отдельные службы.
Если вход выполняется, но всё медленно, проблема не в доступности, а в производительности. В этом случае смотрите загрузку CPU, памяти и дисковой подсистемы на сервере СУБД, длительные запросы (в MS SQL — через динамические представления sys.dm_exec_requests или Activity Monitor) и настройки кластера 1С: количество рабочих процессов, объём памяти на процесс.
Для расследования инцидентов включите и проанализируйте технологический журнал 1С — он фиксирует события соединений, ошибки СУБД, аварийные завершения rphost. Конфигурация задаётся файлом logcfg.xml в каталоге conf платформы. Держать полный журнал включённым постоянно не стоит: на нагруженных системах он создаёт заметную нагрузку на диск. Включайте его на время диагностики с фильтрами по нужным событиям.
- 1Проверьте, что служба агента сервера 1С запущена, а процесс ragent.exe присутствует
- 2Убедитесь, что порты 1540–1541 и диапазон рабочих процессов прослушиваются
- 3Откройте консоль администрирования: кластер доступен, rphost работает, блокировки соединений сняты
- 4Проверьте доступность СУБД: служба, порт, учётная запись, свободное место
- 5С клиентской машины проверьте Test-NetConnection по порту 1541
- 6Выполните тестовый вход в базу и типовые операции
- 7При сбоях включите технологический журнал и проанализируйте ошибки
Типичные ошибки при диагностике и их последствия
Самая распространённая ошибка — перезагрузка сервера «вслепую» до сбора информации. После перезапуска симптомы исчезают вместе с доказательствами, и повторный сбой приходится ждать заново. Сначала зафиксируйте состояние служб, журналы событий и показатели нагрузки, и только потом перезапускайте.
Вторая ошибка — диагностика только со стороны сервера 1С, без проверки СУБД. Значительная часть «падений 1С» на деле является проблемами SQL Server: блокировки, нехватка памяти, переполненный журнал. Третья ошибка — игнорирование версий: после обновления платформы на сервере клиенты со старой версией не смогут подключиться, и это выглядит как отказ сервера.
Профилактика: как не допустить остановки сервера
Регулярная проверка занимает несколько минут и сводится к контролю ключевых точек: служба агента работает, свободное место на дисках сервера и СУБД выше безопасного порога, резервные копии создаются по расписанию и — критически важно — периодически проверяются тестовым восстановлением. Бэкап, который ни разу не восстанавливали, нельзя считать надёжным.
Для серверов с десятками пользователей имеет смысл настроить мониторинг: опрос портов кластера, контроль процессов ragent/rphost, метрики СУБД. Это позволяет узнавать о проблеме раньше пользователей и получать историю показателей, без которой анализ «тормозов» превращается в гадание.
Полезно держать под рукой короткий чек-лист проверки сервера и фиксировать в нём результаты каждого инцидента. Через несколько случаев по записям становятся видны повторяющиеся причины — чаще всего это дисковое пространство и обновления платформы без контроля версий клиентов.
Что важно запомнить
Диагностика сервера 1С идёт по цепочке: служба агента и порты → кластер и блокировки в консоли → доступность СУБД → сеть со стороны клиента → тестовый сеанс. Сначала собирайте журналы и показатели, потом перезапускайте службы, а любые действия с кластером выполняйте только при наличии резервных копий.
Частые вопросы
Какие порты использует сервер 1С и что открыть в брандмауэре?
Стандартно агент использует порт 1540, менеджер кластера — 1541, рабочие процессы — диапазон 1560–1591. Для клиентских подключений достаточно открыть 1541 и диапазон рабочих процессов. Если платформа установлена с нестандартными портами, актуальные значения смотрите в свойствах службы агента.
Служба агента запущена, но клиенты не подключаются. С чего начать?
Проверьте три вещи: доступность порта 1541 с клиентской машины (Test-NetConnection), отсутствие блокировки соединений в консоли администрирования и совпадение версий платформы на сервере и клиенте. Эти три причины покрывают большинство подобных случаев.
Как понять, что проблема в SQL Server, а не в самом сервере 1С?
Признаки проблемы на стороне СУБД: ошибки входа или таймауты в технологическом журнале 1С, недоступность порта СУБД, остановленная служба SQL Server, переполненный журнал транзакций. Если кластер 1С отвечает, а база недоступна — почти всегда дело в СУБД или её учётной записи.
Можно ли перезапускать службу агента при работающих пользователях?
Технически можно, но все активные сеансы завершатся аварийно, а незавершённые транзакции откатятся. Перед перезапуском предупредите пользователей, дождитесь завершения сеансов или принудительно завершите их через консоль администрирования. Плановые перезапуски делайте в нерабочее время.
Сервер работает, но 1С сильно тормозит. Что проверить в первую очередь?
Посмотрите загрузку CPU, памяти и дисков на сервере СУБД, наличие длительных запросов и блокировок, а также объём памяти, занятый процессами rphost. Частые причины — нехватка памяти у SQL Server, фрагментированные индексы и давно не обновлявшаяся статистика.
Где сервер 1С хранит список информационных баз и что будет при его потере?
Реестр кластера хранится в каталоге srvinfo (по умолчанию в каталоге данных агента). При его потере сами базы данных не пострадают, но придётся заново регистрировать все информационные базы в кластере и восстанавливать настройки. Поэтому каталог стоит включать в резервное копирование.