Как проверить скорость сервера 1С Предприятие: диск, процессор, сеть, СУБД

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

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

Что подготовить перед тестированием

Без точки отсчёта любые цифры бесполезны. Сделайте три вещи.

1. Опишите проблему словами пользователя: «медленно проводится документ», «долго формируется отчёт», «всё тормозит в 10:00». От этого зависит, куда смотреть.
2. Запишите конфигурацию железа и ПО: число ядер, объём памяти, тип дисков, версию платформы, СУБД, схему (всё на одном сервере или приложение и база отдельно).
3. Снимите «фон» — нагрузку в рабочее время без тестов. Обычные счётчики системы хватит записывать час-два.

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

Проверка дисковой подсистемы и скорости ввода-вывода

Диск — самый частый виновник. База 1С выполняет множество мелких случайных операций, поэтому важна не «линейная скорость» из рекламы, а задержка и число операций в секунду (IOPS).

Что мерить

• 📌 Задержку чтения и записи. Для SSD нормальная задержка — единицы миллисекунд и меньше. Если она стабильно переваливает за 20–30 мс, диск не справляется.
• 📌 Случайный доступ блоками 4 КБ. Именно так работает СУБД.
• 📌 Длину очереди к диску. Постоянная очередь — признак перегруза.

Чем мерить

Пример для fio: случайное чтение блоками 4 КБ в течение минуты на тестовом файле.

fio --name=randread --rw=randread --bs=4k --size=2G --iodepth=16 --runtime=60 --time_based --filename=/data/fiotest

Для записи замените randread на randwrite. Запускайте на том же разделе, где лежат файлы базы или каталог кластера.

Типичные причины медленного диска

• 💾 Диск общий с другими виртуальными машинами, соседи забирают IOPS.
• 💾 Данные СУБД, журналы транзакций и временные файлы лежат на одном томе.
• 💾 Антивирус сканирует каталоги базы и кластера. Добавьте их в исключения.
• 💾 Контроллер без кеша записи или с севшей батареей.

Процессор и оперативная память

Здесь важно отличить «сервер перегружен» от «одно ядро забито одним тяжёлым процессом». Платформа 1С во многом однопоточна в рамках одного сеанса, поэтому суммарная загрузка 30% не гарантирует, что всё хорошо.

Процессор

Смотрите на загрузку по каждому ядру отдельно и на частоту. Для 1С важнее высокая частота ядра, чем их большое число. Сервер на 32 медленных ядрах по скорости отдельного документа может проиграть четырём быстрым.

• В Windows откройте «Диспетчер задач → Производительность → ЦП» и переключите график на отображение по логическим процессорам.
• Для счётчиков используйте % Processor Time и Processor Queue Length. Очередь, которая постоянно больше двух на ядро, говорит о нехватке мощности.
• В Linux хватит top с клавишей 1 и vmstat 1.

Отдельно смотрите, какие процессы грузят ЦП: rphost (рабочие процессы кластера), ragent, rmngr, 1cv8, процесс СУБД. Если нагрузку создаёт СУБД, переходите к разделу про неё. Если rphost — разбирайте запросы через технологический журнал.

Память

• Запас оперативной памяти нужен и серверу 1С, и СУБД. Если система уходит в своп, любые замеры бессмысленны.
• В Windows следите за Available MBytes и Pages/sec, в Linux за free -m и активностью обмена в vmstat (столбцы si и so).
• Рабочие процессы 1С со временем растут по памяти. Для крупных баз в кластере настраивают перезапуск рабочих процессов по расписанию или по объёму памяти. Параметры находятся в свойствах рабочего сервера и кластера в консоли администрирования.

Сеть и задержки между узлами

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

Быстрая проверка

1. С рабочего места пользователя выполните ping до сервера приложений. Для локальной сети нормальный отклик — около 1 мс, для офиса через VPN — единицы-десятки миллисекунд. Стабильные сотни мс означают проблему.
2. Повторите ping от сервера приложений до сервера СУБД. Здесь задержка должна быть минимальной: 1 мс и меньше.
3. Проверьте потери пакетов: в выводе ping не должно быть пропусков. Для маршрута удобно смотреть tracert (Windows) или traceroute (Linux).
4. Замерьте пропускную способность утилитой iperf3: на одном конце iperf3 -s, на другом iperf3 -c адрес_сервера.

Что искать

• 🌐 Скорость порта ниже ожидаемой (100 Мбит вместо 1 Гбит из-за кабеля или настроек).
• 🌐 Ошибки и пропуски пакетов на сетевом интерфейсе.
• 🌐 Сервер приложений и СУБД в разных площадках или дата-центрах.
• 🌐 Работа удалённых пользователей по обычному клиенту через узкий канал. Для них лучше терминальный доступ или веб-клиент.

Технологический журнал для глубокого анализа

Когда железо выглядит нормально, а пользователи недовольны, нужен технологический журнал (ТЖ). Он записывает события сервера: запросы к СУБД, вызовы, блокировки, исключения, и показывает, какой именно запрос или вызов медленный.

Как включить

ТЖ настраивается файлом logcfg.xml в каталоге conf рядом с установленной платформой. Минимальный пример: писать события обращений к СУБД, которые длились больше секунды.

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\1clogs\dbms" history="4">
    <event>
      <eq property="name" value="DBMSSQL"/>
      <ge property="duration" value="1000000"/>
    </event>
    <property name="all"/>
  </log>
</config>

Здесь DBMSSQL — события для MS SQL Server. Для PostgreSQL используйте DBPOSTGRS. Порог duration задаётся в микросекундах, то есть 1000000 — это одна секунда. Параметр history — сколько часов хранить файлы.

Другие полезные события:

• CALL — серверные вызовы и их длительность;
• TLOCK, TTIMEOUT, TDEADLOCK — управляемые блокировки, таймауты и взаимоблокировки;
• EXCP — исключения.

Как читать

Файлы журнала текстовые, каждая строка начинается со времени и длительности события. Ищите события с самой большой длительностью и смотрите свойства Context (откуда вызван запрос в коде) и Sql или Query (текст запроса). Для разбора больших объёмов удобнее загрузить журнал во внешний инструмент: по ТЖ существуют бесплатные анализаторы и скрипты. Так вы найдёте несколько запросов, которые дают основную потерю времени.

Синтетические тесты и тест Гилева

Синтетика даёт сравнимое число, которое можно показать руководству и повторить после изменений.

Тест Гилева

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

Как пользоваться:

1. Создайте новую пустую базу на проверяемом сервере (не на рабочей).
2. Загрузите обработку теста во внешнюю обработку и откройте её в обычном режиме.
3. Запустите замер два-три раза подряд и возьмите среднее.
4. Запишите значение и условия: нагрузка на сервер, время суток, версию платформы.

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

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

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

Оптимизация СУБД как фактор скорости

Даже на хорошем железе плохо настроенная СУБД всё сводит на нет. Чек-лист по самым частым причинам.

Особенности по СУБД

Конкретные значения параметров подбираются под объём базы и память сервера, поэтому для PostgreSQL ориентируйтесь на рекомендации, подготовленные для 1С, а для MS SQL Server — на практики администрирования, а не на «универсальные» цифры из интернета.

Регламентное обслуживание

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

Как собрать результаты и принять решение

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

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

После каждого изменения повторите тот же замер. Если цифра не сдвинулась, значит, вы лечили не то место.

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