Расчет нагрузки на физический сервер: CPU, RAM и IOPS

Два сервера с одинаковыми 16 ядрами могут по-разному справляться с одной и той же системой: производительность зависит от частоты процессора, объема активных данных в оперативной памяти, характера дисковых операций и задержки накопителей.

Поэтому расчет по числу пользователей или выбор конфигурации “с большим запасом” часто приводит либо к торможению сервисов в часы пик, либо к переплате за невостребованные ресурсы. Ниже разберем, как перевести нагрузку 1С, SQL, файлового сервера или нескольких виртуальных машин в измеримые требования к CPU, памяти и дисковой подсистеме.

Нагрузка начинается с бизнес-сценария, а не характеристик сервера

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

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

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

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

CPU: загрузка, частота, ядра и параллелизм

Процессор нельзя оценивать только по количеству ядер. Для 1С, отдельных SQL-запросов и приложений с ограниченным параллелизмом важна производительность одного ядра: его частота, архитектура и объем кеша. Поэтому современный 12-ядерный CPU иногда оказывается быстрее старой модели с 20–24 ядрами.

Чтобы оценить процессорную нагрузку без грубого пересчета «одно ядро на несколько пользователей», нужно последовательно проверить четыре показателя:

1. Пиковую загрузку CPU. Если она регулярно достигает 90–100% и держится на этом уровне, процессору уже не хватает ресурсов.
2. Продолжительность пиков. Скачок на несколько секунд допустим, тогда как высокая загрузка в течение десятков минут будет влиять на время отклика системы.
3. Очередь процессора. Она показывает, сколько операций ждут свободного вычислительного ресурса, даже если усредненная загрузка выглядит приемлемо.
4. Способность приложения распараллеливать задачи. Виртуальные машины и независимые сервисы обычно хорошо распределяются между ядрами, а отдельная операция может зависеть от скорости одного потока.

Логические потоки при этом нельзя считать полноценными физическими ядрами: многопоточность увеличивает производительность, но не удваивает ее. В расчетный пик разумно сохранять загрузку CPU примерно на уровне 70–80%, оставляя резерв для фоновых процессов и кратковременных всплесков.

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

RAM: рабочий объем данных и запас памяти

Размер базы или файлового хранилища нельзя напрямую переводить в объём оперативной памяти. База SQL на 500 ГБ не обязательно требует 500 ГБ RAM: значение имеет рабочий набор данных — таблицы, индексы и запросы, к которым система регулярно обращается. Чем большая его часть помещается в памяти, тем реже сервер читает данные с накопителей.

Чтобы отличить нормальное использование RAM от её реального дефицита, достаточно проверить три признака:

• Объем доступной памяти в часы максимальной нагрузки;
• Частоту обращения к файлу подкачки и число жёстких страничных ошибок;
• Изменение времени отклика приложений и задержки дисков при заполнении RAM.

Высокая занятость памяти сама по себе не говорит о проблеме. Операционная система и СУБД используют свободный объем для кеширования, поэтому показатель 85–90% может оставаться нормальным, если подкачка не растет, а приложения работают стабильно.

Для сервера виртуализации расчет начинают с суммы максимального потребления всех VM, затем добавляют память для гипервизора и резерв на пики. Например, четыре виртуальные машины, которым требуется 12, 16, 24 и 32 ГБ, вместе потребляют 84 ГБ. В такой ситуации практической отправной точкой станет конфигурация на 128 ГБ. Она оставит около 30% запаса для служебных процессов и роста нагрузки. Желательно также сохранить свободные слоты DIMM, чтобы в будущем увеличить RAM без замены уже установленных модулей.

Storage: IOPS, latency и throughput

Дисковую подсистему часто выбирают по объему накопителей, хотя свободные терабайты ничего не говорят о скорости работы приложений. Для расчета важны три связанные, но не взаимозаменяемые характеристики:

1. IOPS — количество операций чтения и записи в секунду. Показатель особенно важен для SQL, 1С и виртуальных машин с множеством мелких случайных обращений.
2. Latency — время выполнения одной операции. Даже большой запас IOPS не спасёт систему, если запросы регулярно ожидают диск по 15–20 мс.
3. Throughput — пропускная способность в МБ/с. Она выходит на первый план при резервном копировании, передаче крупных файлов и последовательном чтении данных.

Заявленные производителем IOPS нельзя использовать в расчёте без уточнений. Результат зависит от размера блока, соотношения чтения и записи, глубины очереди и типа RAID. Например, массив RAID 5 или RAID 6 экономнее расходует полезную емкость, но при записи выполняет дополнительные операции для расчета четности. RAID 10 требует больше дисков, зато обычно обеспечивает более предсказуемую задержку под смешанной нагрузкой.

Метрики действующей системы нужно снимать в пиковые часы и оценивать не только по среднему значению, но и по редким задержкам. Если latency резко растёт во время отчётов или резервного копирования, накопители либо RAID-контроллер уже стали узким местом. В новой конфигурации также учитывают рост базы и оставляют запас по производительности, а не только по ёмкости.

Финальный расчет конфигурации и проверка запаса

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

1. Бизнес-сценарий. Приложения, количество одновременно активных пользователей, фоновые процессы и пиковые операции.
2. CPU. Фактическое потребление вычислительной мощности, производительность одного ядра и способность программ распараллеливать задачи.
3. RAM. Рабочий объём данных, память виртуальных машин и служебные расходы операционной системы или гипервизора.
4. Storage. Пиковые IOPS, задержка, пропускная способность, соотношение чтения и записи.
5. Резерв. Обычно 20–30% по ключевым ресурсам с учетом роста нагрузки и планового срока эксплуатации.

Допустим, существующая система использует эквивалент шести физических ядер, до 84 ГБ RAM и достигает 8 000 IOPS в часы пик. После добавления 25% запаса расчетная потребность составит 7,5 ядра, 105 ГБ памяти и 10 000 IOPS. Практической основой станет сервер с 8–12 производительными ядрами, 128 ГБ RAM и дисковым массивом, способным удерживать требуемые IOPS без резкого роста latency.

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