Документы проводятся, отчёты формируются, обмены не падают. После подключения пользователей проведение замедляется, а закрытие месяца растягивается. Функциональная проверка подтвердила исправность операций, но не готовность системы к рабочей нагрузке.
Нагрузочный тест нужен до покупки нового сервера. Он показывает предел системы и отделяет нехватку ресурсов от блокировок, фоновых заданий и одной тяжёлой операции. Ниже — сценарий для офиса с 50 активными сеансами. Его можно пересчитать под другую нагрузку.
Воспроизведите рабочий пик, а не вход пяти пользователей
Начните с операций, которые пересекаются в напряжённый час. Один сотрудник проводит документы, другой меняет справочники, третий строит тяжёлый отчёт. Одновременная запись особенно полезна: практическая методика школы «Учитель-програм» использует её для поиска блокировок в СУБД.
Не заменяйте этот сценарий открытием формы или входом в базу. Такой тест проверит авторизацию и запуск клиента, но не проведение документов и конкуренцию за данные.
Возьмём типовой пример: 50 активных операторов, одна клиент-серверная база и заметный пик в конце дня. Это исходные данные для расчёта, а не универсальная норма для любого офиса.
| Операция | Кто выполняет | Что измерять | Признак сбоя |
|---|---|---|---|
| Проведение документа | Операторы продаж или склада | Время от команды до завершения | Задержка растёт вместе с числом сеансов |
| Запись справочника | Несколько операторов одновременно | Время записи и ожидания СУБД | Появляются блокировки или таймауты |
| Тяжёлый отчёт | Бухгалтер или руководитель | Время формирования и серверные вызовы | Отчёт замедляет остальные операции |
| Фоновое задание | Сервер 1С по расписанию | Длительность и потребление ресурсов | В момент запуска тормозят все сеансы |
Тест переносится на рабочую систему только тогда, когда операции и их пересечение повторяют настоящий пик.
Размер базы тоже влияет на результат. В методике школы «Учитель-програм» тестовый набор данных занимает не меньше 80% продуктивной базы. На маленькой копии СУБД иначе использует кэш, строит планы запросов и читает страницы с диска.
Если продуктивная база занимает 500 ГБ, для стенда подготовьте не меньше 400 ГБ: 500 × 0,8 = 400. При другом размере умножьте объём своей базы на 0,8. Это расчёт нижней границы для описанной методики, а не требование фирмы «1С».
Время операций фиксируйте одинаковым способом во всех прогонах. Школа «Учитель-програм» предлагает обработку «Замер производительности» и технологический журнал. Не сравнивайте один прогон по ощущениям пользователей, а другой — по записи секундомера.
Поднимайте нагрузку ступенями
Резкий запуск всех виртуальных пользователей покажет реакцию на всплеск, но скроет рабочую границу. Сначала увеличивайте число операторов постепенно. Тогда на графиках будет видно, после какой ступени растут задержки.
Практическая методика школы «Учитель-програм» предлагает добавлять 10–20% операторов каждые 10–15 минут. Для примера возьмём верхнюю границу: рост на 20% через 15 минут.
Расчёт выглядит так:
N следующей ступени = N текущей × 1,2
Из 50 операторов получаются ступени 50, 60, 72 и 86. Последнее значение округлено: 72 × 1,2 = 86,4. Полный прогон займёт 45 минут после выхода на первую ступень.
| Интервал | Активные операторы | Что сохранить |
|---|---|---|
| 0–15 минут | 50 | Время операций, показатели ОС, ожидания СУБД |
| 15–30 минут | 60 | Те же показатели без смены сценария |
| 30–45 минут | 72 | Момент начала задержек и изменившийся ресурс |
| 45–60 минут | 86 | Поведение системы выше исходного пика |
Ступени отвечают на главный вопрос: где система перестаёт выдерживать рост нагрузки при неизменном наборе операций.
Если стенд близок к рабочему контуру, начните с шага 10%. Формула изменится на N × 1,1, а интервалы останутся прежними. Не меняйте одновременно длительность ступени, состав операций и число пользователей: сравнивать результаты станет трудно.
После ступенчатого прогона проведите отдельный тест всплеска. Та же методика задаёт диапазон от трёх до пяти базовых нагрузок. Для 50 операторов это 150–250 одновременных операторов: 50 × 3 и 50 × 5.
Всплеск не задаёт рабочий норматив. Он показывает, что произойдёт при массовом входе после обрыва связи или одновременном запуске общей операции.
Записывайте ресурсы и ожидания в одном интервале
Одного времени проведения недостаточно. Пользователь видит задержку, но не знает, где она возникла: в rphost, СУБД, хранилище или сети. Нужна единая временная шкала для операций и инфраструктуры.
Штатный Центр управления производительностью фирмы «1С» собирает серверные вызовы, запросы к СУБД и ожидания на блокировках. Он также фиксирует взаимоблокировки, таймауты и счётчики операционной системы.
Для подключения ЦУП не требуется менять код исследуемой базы или состав компонентов сервера 1С. История показателей хранится в отдельной информационной базе. Поэтому два прогона можно сравнить на одинаковом временном интервале.
Обычный мониторинг ЦУП, по документации фирмы «1С», не снижает производительность исследуемой системы. Исключение — показатели группы «Анализ» с включённой записью. Аналитическую запись запускайте только на нужном интервале: сама запись может замедлить базу.
Для SQL Server сохраните базовую точку перед первой ступенью. Порядок настройки Query Store, DMV и Performance Monitor описан в руководстве по наблюдению за SQL Server под нагрузкой 1С.
| Что видит пользователь | Что проверить | Чем подтвердить | Какую правку испытать |
|---|---|---|---|
| Все сеансы замедляются по мере роста нагрузки | CPU и распределение работы по ядрам | Загрузка процессора, очередь, перекос по ядрам | Распределение рабочих процессов или ресурс CPU |
| После перезапуска быстро, затем снова медленно | RAM и подкачку | Свободная память, paging, рост rphost | Лимиты и распределение рабочих процессов |
| Проведение замирает на несколько секунд | Дисковую подсистему | Задержки чтения и записи, очередь, свободное место | Убрать конкурирующую задачу или проверить хранилище |
| Удалённые сеансы медленнее офисных | Сеть и VPN | Потери пакетов, ошибки интерфейса, нестабильный RTT | Проверить канал и маршрут до сервера |
| Отдельные операции периодически останавливаются | СУБД | Ожидания, блокировки, долгие транзакции | Исправить запрос, расписание или конкурирующую операцию |
| Тормозит один сеанс при спокойных ресурсах | Конкретную операцию | Серверные вызовы и потребление по сеансу | Разбирать саму операцию, а не менять сервер |
Таблица отделяет общий дефицит ресурса от локальной проблемы. Она не задаёт универсальных порогов: критичен момент, когда задержка операции совпала с изменением показателя.
Признаки в таблице собраны по диагностическому материалу EFSOL о замедлении 1С. Например, нехватку CPU подтверждают загрузка, очередь процессора и перекос по ядрам. Для памяти смотрят свободный объём и подкачку, для диска — задержки и очередь.
Сетевую причину подтверждают потери пакетов и нестабильный RTT. Проблему СУБД — ожидания, блокировки, взаимоблокировки и долгие транзакции. Если нужно локализовать задержку раньше теста, используйте порядок поиска причины от операции до серверного слоя.
Не покупайте сервер по одному пику CPU
Высокая загрузка процессора во время тяжёлого отчёта ещё не доказывает нехватку CPU. Проверьте, замедлились ли остальные операции, выросла ли очередь и повторился ли признак на следующей ступени.
То же относится к памяти. Малый остаток RAM без подкачки не равен дефициту. Ищите совместное появление двух признаков: задержек операций и paging на том же интервале.
Диск проверяйте не только во время проведения. По материалу EFSOL, задержки могут совпадать с резервным копированием, антивирусной проверкой, снимком хранилища или регламентным заданием. В таком случае покупка новых накопителей лечит не причину, а расписание.
Если проблема проявляется только при закрытии месяца на PostgreSQL, выделите эту операцию в отдельный прогон. Для неё пригодится порядок диагностики PostgreSQL при медленном закрытии месяца.
Меняйте один параметр за прогон
После первого теста выберите одно подтверждённое ограничение. Измените один параметр: настройку СУБД, расписание фонового задания, распределение rphost или ресурс сервера. Затем повторите тот же сценарий.
Сохраните число пользователей, длительность ступеней, состав операций и объём базы. Если поменять всё сразу, улучшение нельзя будет связать с конкретной правкой.
| Найденное ограничение | Проверяемая правка | Что должно измениться | Когда откатить |
|---|---|---|---|
| Очередь CPU растёт вместе с задержкой | Изменить распределение рабочих процессов | Очередь и время операций растут позже | Задержка осталась или перешла на другой слой |
| Подкачка появляется к третьей ступени | Скорректировать лимиты процессов | Paging исчезает на том же интервале | Процессы завершаются или растёт расход памяти |
| Диск занят фоновой задачей | Перенести задачу за пределы теста | Пропадают замирания при записи | Рабочее расписание стало неприемлемым |
| Операции ждут одну транзакцию | Изменить запрос или расписание | Сокращаются ожидания и время операции | Возникают новые блокировки или ошибки |
| Потери появляются только через VPN | Исправить канал или маршрут | RTT стабилизируется, задержка уходит | На локальных сеансах результат не меняется |
Правка доказана, когда повторный прогон убрал исходный признак. Заодно проверьте соседние показатели: ограничение могло перейти с CPU на диск или с диска на СУБД.
История ЦУП помогает сопоставить прогоны. Для испытания самого оборудования заранее зафиксируйте версии платформы, СУБД и операционной системы. Полный набор условий есть в правилах сопоставимого испытания серверного стенда.
Стенд можно арендовать только на время прогона
Отдельный сервер для редких испытаний не обязательно держать весь месяц. Дмитрий Овчаренко, технический архитектор «КОРУС Консалтинг», описал на Infostart проект с временным облачным стендом в Selectel.
В проекте провели 10 запусков по 8 часов за 30 дней для нагрузки в 1000 пользователей. Классическая аренда стоила 360 000 рублей, а включение мощностей только на время тестов — 48 000 рублей.
Это стоимость одного проекта с конкретной архитектурой, а не рыночный тариф. Сравнение полезно как модель расходов: оплачивать весь месяц либо только часы подготовки и прогона.
Если тест подтвердил постоянный дефицит ресурса, переходите от диагностики к конфигурации. Состав узлов под измеренную нагрузку можно получить через расчёт серверного оборудования для конкретного контура 1С.
Порядок прогона для 50 активных сеансов
Перед испытанием зафиксируйте исходную конфигурацию и не меняйте её до конца первого прогона.
- Соберите сценарий из проведения документов, записи справочников, тяжёлого отчёта и фонового задания.
- Подготовьте тестовую базу объёмом не меньше 80% продуктивной.
- Запустите ступени 50, 60, 72 и 86 операторов по 15 минут.
- На каждой ступени сохраните время операций, показатели ОС и ожидания СУБД.
- Отдельно проверьте всплеск от 150 до 250 операторов.
- Найдите показатель, изменение которого совпало с задержкой.
- Внесите одну правку и повторите прогон без изменения сценария.
Если задержка совпала с очередью CPU, подкачкой, дисковыми задержками, потерями сети или ожиданиями СУБД, проверяйте этот слой. Если инфраструктура спокойна, ищите отдельную операцию, сеанс или фоновое задание.
Принимайте правку только после повторного прогона. Результат должен убрать подтверждённый признак и не перенести ограничение на соседний ресурс.