Бенчмарки VPS: как протестировать CPU, диск и сеть

Активация виртуального сервера и получение письма с root-доступом — это момент, когда большинство администраторов сразу начинают накатывать Docker, веб-сервер или переносить боевые базы данных. Это распространенная тактическая ошибка.

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

Разберем системный подход к бенчмаркингу «чистого» VPS: от комплексных автоматических скриптов до точечных замеров дисковой подсистемы и сетевых маршрутов.

Экспресс-диагностика железа: проверяем паспортные данные

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

Выполните базовую команду:

lscpu

На что обратить внимание в выводе:

• Model name: Реальная модель процессора (например, AMD EPYC, Intel Xeon Gold или потребительские Ryzen/Core i9).

• CPU MHz / CPU max MHz: Базовая и фактическая частота. Если частота ядра принудительно зажата ниже номинала (например, 1.8–2.0 GHz вместо заявленных 3.0+ GHz), хостер использует энергосберегающие или искуственно заниженные профили.

• Flags: Наличие современных инструкций (aes для аппаратного шифрования, avx2 / avx512 для векторных вычислений). Их отсутствие говорит о том, что гипервизор запускает виртуальную машину в режиме совместимости со старыми CPU (qemu64/kvm64), что снижает производительность в криптографии и базах данных на 20–40%.

Комплексный стресс-тест: утилита YABS

Стандартом первичной оценки серверов в DevOps-сообществе является скрипт YABS (Yet Another Bench Script). Он выполняет три ключевые задачи: собирает системную информацию, запускает бенчмарк диска через fio, тестирует сеть через iperf3 до ключевых мировых точек и прогоняет стресс-тест процессора через Geekbench.

Запуск утилиты на чистом сервере:

curl -sL yabs.sh | bash

(Если нужно сэкономить трафик или прогнать тест быстрее, флаг -5 отключит длительный сетевой тест: curl -sL yabs.sh | bash -s -- -5).

 YABS: Результаты Geekbench 6
Single-Core Score:  1850  (Отклик одиночных потоков PHP / Node)
Multi-Core Score:   3620  (Параллельная обработка микросервисов)

Как интерпретировать результаты:

1. Single-Core Score: Критически важен для веб-серверов, интерпретируемых языков (PHP, Python, Ruby), монопоточных сред (Node.js) и СУБД под обработку сложных одиночных запросов. Значения выше 1500–1800 баллов в Geekbench 6 считаются отличным результатом для современного облака.

2. Multi-Core Score: Показывает суммарную масштабируемость при параллельной компиляции, работе воркеров или микросервисной архитектуре.

Глубокое тестирование диска: ищем скрытые лимиты IOPS через fio

Встроенные в ОС утилиты вроде dd тестируют исключительно линейную последовательную запись больших блоков данных. В реальной жизни веб-сервер и базы данных работают с рандомным чтением и записью мелкими блоками по 4 КБ с множественными параллельными очередями.

Для детального тестирования используем fio (Flexible I/O Tester):

apt-get install -y fio || yum install -y fio

Тест. Случайное чтение и запись (Random Read/Write 4K)

Имитирует типовую нагрузку реляционной базы данных (PostgreSQL / MySQL):

fio --name=random-rw --ioengine=libaio --rw=randrw --rwmixread=75 --bs=4k \
    --iodepth=64 --numjobs=2 --size=2G --runtime=60 --time_based \
    --direct=1 --group_reporting --filename=test_fio.bin

Результат хорошего Enterprise NVMe:
  read:  IOPS=85.4k, BW=334MiB/s, lat (usec): min=42, max=1820, avg=112.4
  write: IOPS=28.5k, BW=111MiB/s, lat (usec): min=38, max=2104, avg=145.8

На какие метрики смотреть:

• IOPS: Количество операций в секунду. Для качественного серверного NVMe суммарный показатель 4K не должен опускаться ниже 40 000 – 80 000 IOPS. Если значение застряло на отметке 1000, 3000 или 5000 IOPS — хостинг жестко ограничивает тариф программным шейпером (IOPS Limit).

• lat (avg / 99.00th percentile): Задержка отклика. Среднее значение (avg) для NVMe должно измеряться в микросекундах (usec). Если задержка переходит в миллисекунды (msec), под нагрузкой база данных будет создавать длинные очереди транзакций.

Не забудьте удалить тестовый файл после проверки:

rm -f test_fio.bin

Поиск шумных соседей: CPU Steal Time

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

Это явление фиксируется системной метрикой %st (Steal Time).

Как проверить Steal Time на практике:

Запустите стресс-тест всех доступных ядер на 60 секунд:

apt-get install -y stress || yum install -y stress
stress --cpu $(nproc) --timeout 60s &
top -b -n 1 | grep "%Cpu(s)"

Посмотрите на последнее значение строки %Cpu(s) — st:

• До 2–3%: Нормальный показатель для публичных облаков.

• Выше 10–15%: На физическом сервере присутствует жесткий оверселлинг ядер. Такой сервер не подходит для продакшна с чувствительным таймингом отклика.

Проверка реальной пропускной способности сети (iperf3)

Заявленный в тарифе «порт 1 Gbps» часто означает лишь скорость подключения материнской платы хоста к стойковому коммутатору. Реальная пропускная способность за пределы дата-центра может существенно отличаться.

Для тестирования прямого сетевого канала используйте iperf3:

apt-get install -y iperf3 || yum install -y iperf3

Подключитесь к одному из публичных серверов iperf3 (выбирайте узел, географически близкий к вашей целевой аудитории):

# Тест в 4 параллельных потока на отдачу (upload)
iperf3 -c speedtest.serverius.net -P 4

# Тест в 4 параллельных потока на прием (download)
iperf3 -c speedtest.serverius.net -P 4 -R

Если по результатам нескольких тестов скорость не поднимается выше 100–150 Мбит/с при заявленном гигабитном порте, а задержки (jitter) скачут — хостинг ограничивает скорость на уровне виртуального порта или использует загруженные аплинки.

Сводный чек-лист тестирования VPS сервера

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