Что замерить перед покупкой сервера для 1С? Полный чек-лист метрик

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

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

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

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

1. Типовые действия пользователей. Открытие форм, поиск, проведение документов и формирование обычных отчетов.

2. Тяжёлые операции. Расчет себестоимости, начисление зарплаты, перепроведение документов и построение аналитических отчетов.

3. Фоновые процессы. Обмены, синхронизации, загрузка данных и регламентные задания.

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

Для каждой критичной операции фиксируют время начала и завершения, число одновременно работающих пользователей и состояние инфраструктуры в тот же интервал. Лучше сохранять не только среднее время выполнения, но и 95-й процентиль — значение, быстрее которого завершается 95% операций. Он показывает редкие, но регулярные замедления, которые средняя цифра обычно скрывает.

CPU, память и дисковая задержка как единый профиль

Процессор, оперативную память и дисковую подсистему нельзя оценивать по отдельности. Например, высокая загрузка CPU при стабильной задержке дисков указывает на нехватку вычислительной мощности, а медленные операции при умеренной загрузке процессора могут быть связаны с ожиданием ввода-вывода. Большой объем свободной RAM тоже не всегда означает избыток памяти: часть данных могла просто не попасть в кеш из-за особенностей текущего сценария.

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

Исходные показатели удобнее сразу свести в таблицу для передачи интегратору или поставщику:

Все значения нужно снимать в одни и те же интервалы. Отдельный пик CPU или дисковой очереди мало что объясняет без понимания, какая операция выполнялась в этот момент и как долго сохранялась нагрузка.

Разделение нагрузки платформы и СУБД

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

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

• Для платформы 1С фиксируют загрузку CPU и рабочий набор процессов rphost, количество активных сеансов, фоновые задания и длительность серверных вызовов;

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

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

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

Минимальный период наблюдения перед расчетом

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

Чтобы наблюдение охватило разные режимы работы, в график замеров включают три типа интервалов:

1. Обычный рабочий день со стандартным количеством активных пользователей.

2. Период максимальной одновременности: утро, конец смены или массовое проведение документов.

3. Окно тяжелых регламентных операций, резервного копирования, обменов и обслуживания базы.

Системные показатели в пиковые часы желательно сохранять с интервалом 15–30 секунд, а при фоновом наблюдении — не реже одного раза в минуту. Одновременно ведут журнал событий: отмечают обновления, запуск антивирусной проверки, создание резервной копии, импорт данных и другие действия, способные исказить картину.

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