Как проверить сервер 1С: практическая инструкция по диагностике

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

Под «сервером 1С» обычно понимают связку из трёх компонентов: агент сервера 1С:Предприятия (ragent), сервер СУБД (чаще MS SQL Server или PostgreSQL) и саму операционную систему с дисковой подсистемой. Проблема может скрываться в любом из них, поэтому проверять нужно последовательно, а не хаотично перезапускать службы.

Большинство диагностических операций безопасны: просмотр журналов, счётчиков производительности и состояния служб ничего не ломает. Осторожность требуется только при перезапуске служб, изменении настроек СУБД и очистке каталогов — об этом ниже отдельные предупреждения.

Проверка состояния служб сервера 1С

Первый шаг — убедиться, что агент сервера 1С:Предприятия запущен. На Windows откройте оснастку «Службы» (services.msc) и найдите службу «Агент сервера 1С:Предприятия» с номером версии платформы. Статус должен быть «Выполняется», тип запуска — «Автоматически». Если служба остановлена, попытайтесь запустить её и сразу проверьте журнал событий Windows: причина отказа обычно записывается туда.

На Linux проверка выполняется через systemctl. Служба обычно называется srv1cv8 с указанием версии платформы.

systemctl status srv1cv8-8.3.24-x86_64

Если служба падает сразу после запуска, типичные причины — повреждённый реестр кластера (каталог srvinfo), недостаток прав у учётной записи службы или конфликт портов. Перед любыми действиями с каталогом srvinfo сделайте его копию: там хранится список баз кластера, и его потеря означает необходимость пересоздавать регистрацию информационных баз вручную.

Проверка сетевой доступности и портов

Клиенты подключаются к серверу 1С через стандартные порты: 1540 (агент), 1541 (рабочие процессы), 1560-1591 (диапазон рабочих процессов по умолчанию). Если клиенты не видят сервер, проверьте доступность портов с рабочей станции командой Test-NetConnection в PowerShell или telnet.

Test-NetConnection srv1c -Port 1540

Если порт закрыт, проверьте три вещи: запущен ли агент сервера, открыты ли порты в брандмауэре Windows или firewalld на Linux, не блокирует ли трафик антивирус или сетевое оборудование. Частая ситуация — после обновления платформы создаётся новая служба с другим именем, а правила брандмауэра привязаны к старой.

Также проверьте разрешение имён: команда ping по имени сервера должна возвращать правильный IP-адрес. Проблемы с DNS часто маскируются под «сервер не работает», хотя сам сервер исправен.

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

Сервер 1С сам по себе не хранит данные — он работает через СУБД. Если агент запущен, но базы недоступны, проблема почти всегда на стороне SQL-сервера. Убедитесь, что служба SQL Server (или postgres) запущена, и проверьте подключение к конкретной базе через Management Studio или psql под учётной записью, от имени которой работает сервер 1С.

Обратите внимание на состояние баз данных: база в статусе Suspect, Restoring или Offline недоступна для 1С, и пользователи получат ошибку соединения. Причины перевода базы в Suspect — повреждение файлов данных, переполнение диска, аварийное завершение работы. Восстановление такой базы — операция с риском потери данных, её лучше выполнять из резервной копии или с привлечением специалиста по СУБД.

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

Диагностика производительности: память, диски, процессор

Медленная работа 1С чаще всего связана с тремя ресурсами: оперативной памятью, скоростью дисковой подсистемы и блокировками в СУБД. Быструю оценку даёт стандартный монитор ресурсов Windows (resmon) или утилиты top, iostat на Linux.

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

Дисковая подсистема критична для СУБД. Тревожные признаки — высокая длина очереди диска (устойчиво выше 2 на физический диск), большое время отклика (десятки миллисекунд и выше на операциях чтения/записи). Файлы данных и журналы транзакций рекомендуется размещать на разных физических дисках или на быстрых SSD.

Анализ журналов: где искать причину сбоев

Три источника информации о сбоях: журнал событий Windows (или syslog/journald на Linux), журнал регистрации 1С и технологический журнал платформы. Журнал событий ОС покажет падения служб и ошибки оборудования. Журнал регистрации 1С (доступен в конфигураторе) фиксирует ошибки на уровне прикладной логики.

Технологический журнал — самый мощный инструмент, но по умолчанию он выключен. Включается через файл logcfg.xml, размещённый в каталоге conf сервера. В нём можно настроить запись долгих запросов, блокировок, исключений и дампов аварийного завершения. После диагностики журнал рекомендуется сократить или отключить: подробная запись заметно нагружает диск.

Проверка со стороны клиента и консоли кластера

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

Проверьте счётчик лицензий: если пользователи получают сообщение «не найдено свободной лицензии», посмотрите, кто занял сеансы. Частая причина — незакрытые сеансы на терминальном сервере или фоновые задания, запущенные под отдельными пользователями.

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

1. 1
   Проверьте, что службы агента сервера 1С и СУБД запущены
2. 2
   Проверьте доступность портов 1540–1541 с клиентской машины
3. 3
   Убедитесь, что база в СУБД в статусе Online и есть свободное место на дисках
4. 4
   Откройте консоль кластера: проверьте сеансы, рабочие процессы и лицензии
5. 5
   Оцените нагрузку: память, очередь диска, загрузку процессора
6. 6
   Изучите журналы: события ОС, журнал регистрации, при необходимости включите техножурнал
7. 7
   Проверьте базу с самого сервера, чтобы отделить сетевую проблему от серверной

Типичные ошибки при проверке и профилактике

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

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

Наконец, проверяйте резервные копии не по факту их создания, а по факту восстановления. Тестовое восстановление копии на отдельный сервер хотя бы раз в квартал — единственный способ убедиться, что копии рабочие.

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