Как проверить VDS до покупки: ядра, память, диск?
Слово VDS не закреплено ни за одной технологией. У одного это машина KVM, у другого контейнер, у третьего просто тариф подороже с пометкой dedicated. За одинаковой строкой характеристик стоят разные модели распределения ресурсов, и утренний тест дает результат, который вечером не повторится.
Что стоит выяснить до тестов? KVM запускает гостя с собственным ядром на аппаратной виртуализации, OpenVZ и LXC делят ядро хоста. Распространенное заблуждение: KVM якобы исключает оверкоммит. Не исключает, провайдер назначает машинам больше vCPU и памяти, чем есть на хосте. Отсюда вопросы к тарифу. Закреплены ли vCPU за физическими процессорами. Зарезервирована ли память. Есть ли лимит IOPS и что при его превышении. Слова dedicated, isolated и NVMe без этих ответов не значат ничего.
Ядра. Под dedicated понимают физическое ядро, закрепленное за машиной. Pinning эксклюзивности не дает: на тот же процессор оператор может посадить чужие vCPU. Проверяется это наблюдением.
mpstat -P ALL 1 60
Колонка %steal показывает время, когда система готова работать, а процессор ей не дали. Важна повторяемость: единичный всплеск это шум, рост в одни часы это конкуренция. На контейнерном тарифе лимит виден как троттлинг, steal остается низким.
cat /sys/fs/cgroup/cpu.max /sys/fs/cgroup/cpu.stat
200000 100000 nr_throttled 1843 throttled_usec 21904331
Ненулевой nr_throttled означает, что режет лимит, а не сосед. В виртуальной машине таких значений не будет. Дальше sysbench в один поток и на всех ядрах, одна версия утилиты и один cpu-max-prime на кандидатах.
sysbench cpu --threads=1 --cpu-max-prime=20000 --time=60 run sysbench cpu --threads=$(nproc) --cpu-max-prime=20000 --time=60 run
Строгого удвоения при удвоении потоков не будет, мешают кеш и шина памяти. Настораживает обратное: многопоточный результат равен однопоточному, а mpstat показывает steal.
Память. Объем в тарифе это то, что видит гостевая система, а не то, что зарезервировано на хосте. При ballooning драйвер отдает страницы гипервизору, и наличие устройства подтверждает механизм, но не политику.
free -m && swapon --show stress-ng --vm 1 --vm-bytes 70% --vm-keep --timeout 10m --metrics-brief
Тест гоняйте на пустой машине и параллельно смотрите vmstat. Использование swap само по себе ни о чем не говорит, оно зависит от настроек гостя. Тревожат устойчивые si и so при умеренной нагрузке и падение MemAvailable. Если процесс исчез раньше срока, ответ в журнале ядра.
journalctl -k --since "-15 min" | grep -Ei "oom-kill|killed process"
Диск. Лимит в 20000 IOPS без размера блока, соотношения чтения и записи и глубины очереди это просто число. Те же 20000 при iodepth 32 ничего не обещают при iodepth 1, а именно так работает приложение, ждущее ответа на запрос. Файл сначала заполняют целиком, иначе чтение из пустых областей завысит результат.
fio --name=randrw --filename=/var/tmp/fio.test --size=4G \ --rw=randrw --rwmixread=70 --bs=4k --direct=1 --ioengine=libaio \ --iodepth=1 --time_based --runtime=120 --refill_buffers=1 \ --group_reporting --percentile_list=50:95:99:99.9
Затем тот же вызов с iodepth 32 и проверка в разделе IO depths, достигнута ли глубина. Сохраняйте IOPS и процентили clat, а не среднее. Один прогон шумного соседа не покажет, нужны три в разные часы. Растущий p99 при стабильной медиане это и есть нестабильность.
Как сравнивать? Не складывайте IOPS, миллисекунды и баллы в один рейтинг. Сначала отсеките тарифы, не проходящие пороги приложения, потом расставьте веса: базе важнее p99 диска, агенту сборки процессор, медиасервису исходящая полоса. Для каждого прогона сохраняйте дату, локацию, образ, версии утилит и команду.
Универсального первого места нет. Есть тариф, проходящий ваши пороги трижды подряд в разное время суток.
