Стресс-тест сервера 1С: чем грузить, что мерить и как читать результат

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

Результат любого теста бесполезен без замеров. Нагрузка без счётчиков процессора, диска, памяти и без технологического журнала даёт только цифру «тормозит / не тормозит». Ниже — порядок: зачем, чем, как подготовиться, что гонять и как разбирать итог.

Зачем проверять сервер 1С нагрузкой заранее

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

Нагрузку запускают в таких ситуациях:

• 🖥 покупка или аренда нового сервера — нужно понять, оправдана ли цена;
• 🔄 переезд на другую СУБД, смена версии платформы или SQL Server на PostgreSQL;
• ☁️ перенос в виртуальную среду или облако, где «ядро» не равно физическому ядру;
• 📈 рост числа пользователей: было 20, станет 80;
• 🧩 крупное обновление конфигурации или доработки с тяжёлыми запросами;
• 🐌 жалобы на «тормоза» без понятной причины.

Чем нагружать: от теста Гилёва до ЦНТ

Инструменты различаются по трудоёмкости и по тому, что именно они проверяют.

Тест Гилёва

Тест Гилёва — широко известная внешняя обработка. Она выполняет набор операций (запись справочников, проведение документов, запросы) и выдаёт итог в условных баллах. Чем выше балл, тем быстрее система.

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

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

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

Параллельные реальные сеансы

Самый недорогой способ получить честную картину. Берёте 5–20 тестовых пользователей, каждому даёте сценарий: провести пачку документов, сформировать отчёт, выгрузить печатную форму. Запускаете одновременно и засекаете время.

Минус: сценарии выполняют люди, поэтому воспроизвести тест в точности сложно. Если нужна повторяемость, автоматизируйте действия.

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

Это отдельное решение фирмы 1С для имитации работы большого числа пользователей. Оно записывает действия реального сеанса в сценарий и воспроизводит его в десятках и сотнях копий. Входит в корпоративный инструментарий, поэтому требует отдельного лицензирования и обучения. Для ежедневных задач админа избыточно, для проекта на 300 пользователей — стандартный выбор.

Внешние нагрузчики и свои скрипты

Если пользователи ходят через веб-клиент или вы публикуете HTTP-сервисы, подойдут универсальные инструменты вроде Apache JMeter: он создаёт тысячи запросов к опубликованному адресу. Для тонкого и толстого клиента нужны сценарии на уровне 1С.

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

Что подготовить до запуска

Половина неудачных тестов происходит не из-за сервера, а из-за подготовки. Если тестируете на «живой» базе, вы рискуете уронить работу бухгалтерии, а если на пустой, то результат не похож на реальность.

Среда и данные

• 🗄 Возьмите копию рабочей базы с реальными объёмами. Пустая база не покажет проблем с индексами и планами запросов.
• 🧑‍💻 Разверните копию на отдельной площадке с такой же конфигурацией сервера, что и рабочий. Меньшая машина даёт заниженные результаты, большая — завышенные.
• 🔒 Отключите регламентные задания, рассылки и обмены в копии — иначе тест начнёт отправлять письма и выгружать данные.
• 🕘 Выберите окно, когда на сервере никто не работает : чужая нагрузка исказит замеры.

Базовые замеры «до»

Запишите исходные цифры, иначе сравнивать будет не с чем:

• загрузка процессора и память в простое;
• время запуска клиента и открытия 3–4 типовых форм;
• время проведения пачки из 100 документов;
• время формирования 2–3 самых тяжёлых отчётов.

Настройка наблюдения

На сервере 1С включите сбор счётчиков операционной системы. В Windows это Монитор производительности, в Linux — стандартные утилиты (sar, vmstat, iostat). Параллельно включите технологический журнал 1С на время теста. Он пишет в файлы подробности вызовов, блокировок и запросов к СУБД. Настраивается файлом logcfg.xml в каталоге conf установки платформы.

Какие сценарии гонять

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

Выбор критичных операций

Возьмите статистику из работы базы: какие операции делают чаще всего и какие самые тяжёлые. Обычно получается список из 5–10 пунктов:

• массовое проведение документов (реализации, поступления);
• формирование оборотно-сальдовой ведомости и других тяжёлых отчётов за год;
• закрытие месяца или перерасчёт себестоимости;
• обмен с внешними системами — выгрузка и загрузка пачки данных;
• поиск и открытие списков с отбором;
• параллельная запись в одни и те же регистры (остатки, взаиморасчёты).

Профили нагрузки

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

1. Штатная нагрузка — столько пользователей, сколько работает днём. Цель: убедиться, что время операций в норме.
2. Пиковая — в 1,5–2 раза больше. Цель: найти запас.
3. Предельная — наращивайте число сеансов ступенями (например, по 10 каждые 10 минут), пока время отклика не вырастет в разы. Это точка насыщения.
4. Длительная — штатная нагрузка в течение нескольких часов. Цель: найти утечки памяти и деградацию.

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

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

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

Время отклика и пропускная способность

Главная метрика для пользователя — время операции. Следите за ростом по ступеням нагрузки:

• время почти не меняется при росте числа сеансов — запас есть;
• время растёт плавно — подходите к пределу, закладывайте резерв 30–40%;
• время растёт скачком — вы упёрлись в узкое место, нужно его найти.

Среднее значение обманывает. Смотрите 90-й и 95-й процентиль: если средняя операция идёт 2 секунды, а каждая двадцатая — 40, пользователи будут жаловаться именно на неё.

Куда упёрлось: основные счётчики

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

Что подскажет технологический журнал

В журнале ищите три вещи:

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

Последнее часто неожиданность: сервер почти простаивает, а отклик ужасный. Причина — очередь на блокировку одного регистра.

Оценка по Apdex

Для итоговой оценки удобна методика Apdex: каждой операции задаётся целевое время (например, 1 секунда), и все замеры делятся на три группы — быстрее цели, до четырёх целей, медленнее. Получается одно число от 0 до 1. Выше 0,85 обычно считают хорошим результатом, ниже 0,5 — неприемлемым. Такой показатель удобно показывать руководству.

Что искусственно создаёт лишнюю нагрузку

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

• 🔁 Регламентные задания, которые запускаются слишком часто или одновременно в начале часа.
• 📚 Отчёты за большие периоды без отбора, которые пользователи запускают «на всякий случай».
• 🔌 Старые обмены, которые давно никому не нужны, но всё ещё работают.
• 🧹 Раздувшийся журнал регистрации и разросшиеся служебные таблицы.
• 🗃 Устаревшая статистика и фрагментированные индексы в СУБД.
• 🖱 Ручное закрытие периода в рабочее время, когда параллельно идёт ввод документов.
• 💾 Резервное копирование в часы работы.

Оптимизация сервера после теста

Лечить нужно найденное узкое место, а не всё подряд. Меняйте одну вещь за раз и повторяйте тест, иначе не поймёте, что помогло.

Если упёрлись в железо

• Диски: перенесите базу и журнал транзакций на SSD или NVMe, разнесите их по разным томам.
• Память: добавьте ОЗУ, чтобы кэш СУБД вмещал рабочий набор данных.
• Процессор: для клиент-серверного режима важнее частота ядра, чем их количество — многие операции 1С выполняются в одном потоке.
• Виртуализация: зарезервируйте ресурсы за виртуальной машиной, чтобы соседи не отъедали ядра.

Если упёрлись в настройки

• Настройте автоматическое обслуживание СУБД: обновление статистики и перестроение индексов по расписанию, в нерабочее время.
• Для MS SQL проверьте лимит памяти сервера и параллелизм запросов; для PostgreSQL — размер кэша и параметры планировщика под вашу нагрузку.
• Подберите число рабочих процессов и максимальную память на процесс в кластере 1С под объём ОЗУ.
• Включите режим работы с блокировками, подходящий вашей конфигурации. Решение зависит от версии платформы и самой конфигурации — смотрите рекомендации разработчика типовой конфигурации.

Если упёрлись в код

Это самое частое и самое дешёвое лечение: переписать один запрос иногда даёт больше, чем новый сервер. Типичные находки:

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

Автоматизация и постоянный мониторинг

Разовый тест устаревает через полгода: база растёт, конфигурация обновляется. Лучше сделать проверку регулярной.

Что автоматизировать

• Скрипт, который по расписанию на тестовой копии выполняет 3–5 эталонных операций и записывает время в таблицу. Резкий рост времени сигналит о проблеме раньше пользователей.
• Запуск теста Гилёва после каждого изменения инфраструктуры (обновление гипервизора, замена диска).
• Сохранение результатов в одном месте с датой и версией платформы.

Мониторинг в боевой среде

Постоянное наблюдение заменяет часть стресс-тестов. Достаточно собирать:

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

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

Настройте оповещения: процессор выше 85% дольше 10 минут, задержка диска выше порога, рост очереди ожидания блокировок. Тогда вы узнаете о проблеме по сообщению, а не по звонку из бухгалтерии.

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