Проверка сервера 1С:Предприятия — от замера скорости до нагрузки и отказов

Протестировать сервер 1С — значит проверить три вещи по порядку: что кластер жив и настроен, что железо и сеть не упираются в потолок, и что система держит рабочую нагрузку. Нагрузочные тесты без первых двух шагов бесполезны: вы намерите проблемы, которые видны и без них.

Частая ошибка — запустить «тест производительности» на рабочем сервере в середине дня и по одной цифре решить, что нужен новый сервер. Одна цифра ничего не говорит. Нужна серия замеров в одинаковых условиях и список того, что в этот момент делали сервер, диск и сеть.

Ниже — порядок, который работает для файловой и клиент-серверной схемы, с акцентом на кластер серверов 1С. Все проверки идут от безопасных к тяжёлым.

Подготовка: что зафиксировать до первого теста

Без базовых данных сравнивать будет не с чем. Запишите их один раз и храните рядом с результатами.

• 🖥️ Версия платформы и точная сборка на сервере и на клиентах.
• ⚙️ Число ядер, объём памяти, тип дисков (SSD или HDD), схема RAID.
• 🗄️ СУБД и её версия: PostgreSQL или MS SQL Server, на этом же сервере или на отдельном.
• 👥 Сколько пользователей работает одновременно в пике.
• 🕒 Окно, когда тест не помешает людям: вечер или выходной.

Перед любыми проверками с изменениями сделайте резервную копию базы и настроек кластера. Это правило касается проверки целостности, переиндексации и тестов отказа.

Первичная диагностика: жив ли кластер

Начните с того, что видно за пять минут и ничего не ломает.

Службы и порты

Агент сервера 1С (ragent) должен быть запущен как служба. Менеджер кластера (rmngr) и рабочие процессы (rphost) стартуют уже от него. Проверьте:

1. В оснастке служб Windows (или systemctl status в Linux) агент сервера работает и не перезапускается каждые несколько минут.
2. Порт агента по умолчанию — 1540, менеджер — 1541, рабочие процессы берут порты из диапазона 1560–1591. Если у вас другие значения, сверьте их с настройками кластера.
3. С клиентской машины порты доступны. В PowerShell: Test-NetConnection имя_сервера -Port 1540.

Закрытый брандмауэром диапазон рабочих процессов — типичная причина, когда «подключается, но через раз зависает».

Консоль кластера и утилита rac

В консоли администрирования серверов 1С посмотрите, сколько рабочих серверов, сколько рабочих процессов и сколько сеансов. Те же данные отдаёт rac — консольный клиент сервера администрирования (ras):

rac cluster list
rac session list --cluster=<идентификатор_кластера>
rac process list --cluster=<идентификатор_кластера>

Что искать:

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

Лицензии

Проверьте, что свободных лицензий хватает на пик. Нехватка выглядит как «медленно или не пускает», хотя сервер ни при чём.

Замер скорости работы: тест Гилёва и замер производительности

Два разных инструмента отвечают на два разных вопроса.

Тест Гилёва

Это сторонняя обработка, поэтому берите её только с проверенного источника и сначала запускайте в тестовой базе. Она создаёт временные данные и показывает балл. Правила, чтобы результат имел смысл:

1. Запускайте тест на пустой тестовой базе, а не на рабочей.
2. Делайте три прогона подряд и берите средний. Первый обычно хуже: кэши холодные.
3. Запускайте и с клиента, и с самого сервера. Разница сразу показывает вклад сети.
4. Записывайте не только итог, но и отдельные показатели: если проседает только запись на диск, то и лечить надо диск.

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

Замер производительности по APDEX

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

Мониторинг процессора, памяти, диска и сети

Тест скажет «медленно». Мониторинг покажет, где узко.

Что смотреть в Windows

В perfmon (системный монитор) добавьте счётчики и запишите их в набор данных на несколько часов, захватив рабочий пик:

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

В Linux те же данные дают top/htop, iostat -x 5 и vmstat 5.

Диск — главный подозреваемый

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

Сеть между клиентом, сервером 1С и СУБД

Измерьте задержку между сервером 1С и сервером СУБД командой ping -n 50 сервер_субд. В одной локальной сети она должна быть доли миллисекунды. Если СУБД стоит на другой площадке, любой запрос платит эту задержку многократно, а у 1С запросов тысячи.

Для клиентов по RDP или через веб-доступ отдельно проверьте канал и нагрузку терминального сервера: нередко «тормозит 1С», а на самом деле перегружен терминал.

Технологический журнал: куда уходит время

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

Минимальный пример: писать исключения и долгие вызовы в отдельную папку и хранить сутки:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\1clogs\exceptions" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
  <log location="C:\1clogs\calls" history="24">
    <event>
      <eq property="name" value="CALL"/>
      <ge property="duration" value="3000000"/>
    </event>
    <property name="all"/>
  </log>
</config>

Здесь duration задаётся в микросекундах, поэтому 3000000 — это три секунды.

Какие события включать под задачу

• 🧯 EXCP — исключения, то есть реальные ошибки на сервере.
• 🔒 TLOCK, TTIMEOUT, TDEADLOCK — блокировки, таймауты и взаимоблокировки управляемых блокировок.
• 🐢 CALL с порогом по duration — долгие серверные вызовы.
• 🗃️ DBMSSQL (для MS SQL) или DBPOSTGRS (для PostgreSQL) — запросы к СУБД и их длительность.
• 📉 SDBL — запросы на языке 1С до перевода в SQL.

Как читать результат

Журнал — это текстовые файлы с миллионами строк. Вручную их не осилить: используйте grep, скрипты или специальные анализаторы. Практичный порядок:

1. Найдите самые длинные вызовы по duration.
2. Посмотрите, что у них общего: пользователь, процедура в стеке, конкретная таблица.
3. Если много TLOCK на одном объекте — проблема в конкуренции за блокировки, а не в железе.
4. Если долгие запросы к СУБД — идите к плану запроса и индексам.

Проверка базы: целостность и индексы

Иногда медленно не из-за сервера, а из-за самой базы. Проверка занимает время и требует монопольного доступа, так что планируйте окно.

Тестирование и исправление информационной базы

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

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

Индексы и статистика СУБД

Для клиент-серверной базы регулярные задачи обслуживания такие же, как у любой СУБД:

• 📊 обновление статистики — после больших загрузок и на регулярной основе;
• 🧱 перестроение или реорганизация фрагментированных индексов;
• 🧹 очистка и сжатие, которые у PostgreSQL выполняет VACUUM/автовакуум.

В MS SQL фрагментацию смотрят через системные представления, а перестраивают командой ALTER INDEX ... REBUILD. В PostgreSQL следите, чтобы автовакуум успевал за нагрузкой, иначе таблицы «раздуваются».

Если после обслуживания база заметно быстрее, значит, узким местом были статистика и индексы, а не сервер.

Нагрузочное и стресс-тестирование кластера

Когда базовые проверки пройдены, можно моделировать пик.

Как подойти к нагрузке

1. Возьмите копию боевой базы на тестовом стенде с таким же железом и настройками.
2. Определите сценарии: проведение типовых документов, формирование 2–3 тяжёлых отчётов, фоновые задания.
3. Запускайте их параллельно от нескольких сеансов и поэтапно наращивайте число: 10, 25, 50 пользователей — под ваш реальный пик.
4. На каждом шаге фиксируйте время операции и счётчики из perfmon. Точка, где время растёт непропорционально, и есть предел.

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

Сценарии отказа

Нагрузка — не всё. Проверьте, как система ведёт себя при сбоях, на тестовом стенде:

Частые ошибки при тестировании

• Тестируют один раз и делают выводы. Нужна серия замеров и сравнение с базовой линией.
• Включают ТЖ без фильтров и забивают диск журналом.
• Запускают тест на сервере, где одновременно идёт бэкап или регламентное задание.
• Сравнивают два сервера на разных версиях платформы или СУБД и удивляются разнице.
• Лечат железо там, где причина в блокировках или запросах.

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