Как перегрузить сервер 1С: контролируемое нагрузочное тестирование

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

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

Важно: все эксперименты с нагрузкой проводятся только на тестовом контуре или в нерабочее время с согласования владельца системы. Нагрузочный тест на рабочей базе в разгар дня способен остановить работу компании — это прямая угроза данным и бизнес-процессам.

Что именно нагружается в сервере 1С

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

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

Способы создать нагрузку на сервер

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

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

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

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

Инструменты нагрузочного тестирования

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

Для измерения результатов используют технологический журнал кластера 1С — он фиксирует длительные вызовы, запросы к СУБД, блокировки и ошибки. На стороне Windows полезны системный монитор (Performance Monitor) со счётчиками процессора, памяти и диска, на стороне СУБД — штатные средства мониторинга активности и ожиданий.

logcfg.xml — включение технологического журнала:
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\1c_logs" history="24">
    <event><eq property="name" value="EXCP"/></event>
    <event><eq property="name" value="DBMSSQL"/></event>
    <property name="all"/>
  </log>
</config>

Какие метрики фиксировать во время теста

Главная метрика — время отклика типовой операции: сколько длится проведение документа или построение отчёта при разном числе параллельных пользователей. Нормой считается плавная деградация: время растёт умеренно по мере роста нагрузки. Резкий скачок времени отклика в несколько раз означает, что какой-то ресурс исчерпан.

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

Когда сервер перегружен без всякого теста

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

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

Типичные ошибки при нагрузочных тестах

Частая ошибка — тестировать на пустой или маленькой базе. На базе в несколько гигабайт запросы выполняются быстро, а на реальной базе в сотни гигабайт картина меняется радикально. Тестовый контур должен быть максимально близок к боевому по объёму данных и железу.

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

Что делать с результатами теста

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

Если деградация вызвана прикладным кодом — тяжёлыми отчётами, неоптимальными циклами проведения, лишними запросами в цикле — наращивание железа даст лишь временный эффект. Оптимизация кода и запросов в этом случае основной путь.

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