Оверселлинг в цифрах: как понять, что вам продали воздух

MAATRIX

Тариф обещает «4 vCPU, 8 ГБ RAM», а сервер под привычной нагрузкой вдруг начинает тормозить без видимой причины — вы не единственный, у кого возникает подозрение, что хостинг продал больше ресурсов, чем реально есть на физической машине. Это подозрение можно проверить не спором с поддержкой, а конкретными числами с вашей же виртуалки. Ниже — рабочая методика: что означают заявленные vCPU и RAM на самом деле, как поймать нехватку процессора через steal time, как бенчмарком по часам суток выявить переподписанный хост и как fio показывает разницу между IOPS из прайса и IOPS под вашей нагрузкой.

Что такое оверселлинг и почему это не обман сам по себе

Оверселлинг — это продажа виртуальных ресурсов (vCPU, RAM, дискового пространства) в сумме превышающей то, что физически есть на сервере, в расчёте на то, что арендаторы не упрутся в свои лимиты одновременно. Условно: на хосте с 64 физическими ядрами и 256 ГБ RAM хостинг может продать 30 тарифов по 4 vCPU и 16 ГБ — итого 120 vCPU и 480 ГБ на бумаге, притом что физически доступно вдвое меньше по CPU и почти вдвое меньше по RAM. Звучит как повод для возмущения, но экономически это стандартная модель почти всей индустрии — так же работают авиакомпании, продавая больше билетов, чем мест (не все долетают до вылета), мобильные операторы, продавая безлимитный интернет большему числу абонентов, чем реально выдержит соседняя вышка при одновременной нагрузке, и облачные провайдеры любого масштаба.

Работает это потому, что подавляющее большинство VPS большую часть времени простаивают: сайт с редкими посещениями, тестовый сервер, бот, который просыпается раз в минуту — все они используют считаные проценты выделенного CPU почти всегда. Если бы хостинг продавал ресурсы строго 1:1 с физическим железом (то есть вообще без оверселлинга), тарифы стоили бы в несколько раз дороже — вы бы платили за простаивающие мощности, которые статистически не нужны почти никогда. Умеренный оверселлинг — это, по сути, способ размазать стоимость простаивающего железа между арендаторами и получить в итоге более низкую цену за гигабайт и ядро. Проблема возникает не от самого факта оверселлинга, а от его степени: если хостинг продал не в 1.5-2 раза больше ресурсов, чем есть, а в 5-6 раз, статистика перестаёт спасать, и арендаторы начинают реально мешать друг другу в моменты одновременного пика.

vCPU и RAM в тарифе — это лимит, а не гарантия производительности

Здесь стоит разобраться, что технически означает цифра в тарифе, потому что путаница именно в этом месте порождает половину недопонимания.

vCPU — это не «выделенное физическое ядро», а квота на процессорное время, которую гипервизор (обычно KVM) выдаёт вашей виртуальной машине через планировщик, конкурируя с другими VM на этом же хосте. Технически это часто реализовано через cgroups: у вашей VM есть cpu.cfs_quota_us — верхний потолок процессорного времени за период, который вы не можете превысить, но который не гарантирует, что вам выдадут это время именно тогда, когда оно нужно. Если физическое ядро в конкретный момент занято соседней VM, планировщику приходится ставить вас в очередь — и это никак не противоречит тому, что в тарифе честно написано «4 vCPU». Единственная тарифная модель, где ядро физически закреплено только за вами (CPU pinning, «dedicated vCPU») — это отдельный, обычно более дорогой класс тарифов, и если для вас критична стабильная задержка (торговые роботы, real-time обработка), именно на такой тариф стоит смотреть в первую очередь, а не пытаться вылечить нехватку железа тюнингом.

RAM, в отличие от CPU, оверселлят заметно реже и осторожнее: OOM-килл (когда ядро вынуждено убивать процессы из-за нехватки памяти) — это жёсткий, заметный и неприятный сбой, в отличие от плавного замедления от нехватки CPU-времени, поэтому добросовестные хостинги обычно закладывают память с гораздо меньшим коэффициентом overcommit либо не оверселлят её вовсе. Часть хостингов вместо прямого overcommit используют KSM (Kernel Samepage Merging) — дедупликацию одинаковых страниц памяти между однотипными VM (например, если у десятка виртуалок один и тот же образ ОС в памяти) — это позволяет разместить больше VM на хосте без риска реального overcommit, но эффект от этого механизма сильно зависит от того, насколько похожи гостевые системы, и заранее оценить его вклад со стороны арендатора нельзя.

Практический вывод: если тормозит именно CPU-часть нагрузки при свободной памяти — это, скорее всего, вопрос конкуренции за процессорное время с соседями, и дальше стоит смотреть steal time. Если упирается память (free/vmstat показывают нехватку, растёт swap) — это отдельная история, слабо связанная с оверселлингом CPU, и для неё, если она про производительность виртуализации в целом, полезен разбор где виртуализация теряет производительность.

Steal time: главный сигнал нехватки CPU из-за соседей

Самая прямая метрика, которая отличает «мой код медленный» от «мне не дают процессор» — это steal time, колонка st в vmstat и top. Она считается гостевой ОС и показывает долю времени, когда виртуальной машине было что выполнять, но гипервизор в этот момент отдал физическое ядро другой VM на том же хосте.

Смотрится это одной командой:

vmstat 1

и в последней колонке блока cpu появляется число st. То же самое видно в top в строке %Cpu(s) — там есть отдельный параметр st. Полный разбор механики метрики, включая то, почему её вообще не существует на выделенном железе без виртуализации, и как отличить steal от обычной загрузки us/sy — в отдельной статье steal time: как понять, что сосед по железу ест ваш процессор. Здесь важна практическая сторона: разовое значение st ни о чём не говорит, важна картина за несколько дней при разной нагрузке.

Собрать такую картину можно простым логированием в фоне — например, оставить на сервере скрипт, который раз в 5 минут дописывает значение steal time с меткой времени в файл:

#!/bin/bash
# steal_log.sh — писать raз в 5 минут
while true; do
  ST=$(vmstat 1 2 | tail -1 | awk '{print $17}')
  echo "$(date '+%F %H:%M') st=${ST}" >> ~/steal_log.txt
  sleep 300
done

Запустить в фоне через nohup ./steal_log.sh & или, аккуратнее, systemd-таймером, и оставить на 3-7 дней, захватив и будни, и выходные. Дальше — не нужен строгий норматив, но есть разумный ориентир: короткие всплески steal time в те моменты, когда вы сами грузите процессор (например, во время бэкапа или сборки) — это нормальная конкуренция за ресурс и не повод для тревоги. А вот значения, стабильно держащиеся в районе двузначных чисел в те часы, когда ваша собственная VM практически простаивает — это уже сигнал, что физического CPU на хосте не хватает независимо от того, что делаете именно вы.

Бенчмарк CPU в разное время суток

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

Для теста подойдёт sysbench:

apt install sysbench -y
sysbench cpu --cpu-max-prime=20000 --threads=1 run

В выводе интересна строка total time: (или events per second:) — чем она стабильнее в одинаковых условиях, тем предсказуемее хост. Альтернатива — stress-ng:

stress-ng --cpu 1 --cpu-method fft --timeout 60s --metrics-brief

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

#!/bin/bash
# cpu_bench.sh
RESULT=$(sysbench cpu --cpu-max-prime=20000 --threads=1 run | grep "total time:")
echo "$(date '+%F %H:%M') ${RESULT}" >> /root/cpu_bench.log

0 * * * * /root/cpu_bench.sh

Через несколько суток в логе накапливается таблица «час — время выполнения», которую можно сгруппировать по часу дня (усреднив по нескольким суткам) и посмотреть на разброс между лучшим и худшим часом. Здесь тоже стоит сразу оговориться: это ориентировочная, а не паспортная метрика — точных «нормальных» цифр в процентах для всех хостов не существует, слишком много переменных (модель CPU, число соседей, их профиль нагрузки). Но как эмпирическое правило: небольшие колебания в пределах 10-20% между часами — обычная жизнь любого шеренного хоста, а вот падение производительности в полтора-два раза именно в предсказуемо «пиковые» часы (например, вечер buднего дня, когда у большинства арендаторов на этом хосте больше активности) — это уже не шум, а видимый эффект переподписки.

Диск: сравниваем заявленные IOPS с реальными через fio

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

Ставим fio и гоняем тест случайного чтения блоками 4 КБ (типичный профиль для баз данных):

apt install fio -y
fio --name=randread_test --directory=/tmp --rw=randread \
    --bs=4k --size=1G --numjobs=4 --iodepth=32 \
    --runtime=60 --time_based --group_reporting

Для случайной записи меняем --rw=randread на --rw=randwrite (осторожно с размером и директорией — тест реально пишет данные на диск). В выводе смотрим на строки IOPS= и clat (completion latency) — не только среднее значение, но и p99, потому что именно хвостовые задержки обычно выдают проблему раньше, чем среднее.

Дальше — сравниваем полученную цифру с той, что заявлена в характеристиках тарифа. Разница в разы вниз — это ожидаемо и само по себе не повод для претензий: реальный IOPS почти всегда ниже паспортного, потому что паспортный снят в идеальных условиях очереди, которых в реальной эксплуатации не бывает. Показательнее — та же логика, что и с CPU: прогнать одинаковый fio-тест несколько раз в течение суток (например, через cron, аналогично скрипту для CPU выше) и посмотреть, скачет ли IOPS и latency в зависимости от часа. Если днём диск выдаёт стабильно в разы меньше IOPS, чем ночью, при той же самой команде — это диск-эквивалент steal time, только для дискового ввода-вывода, и означает, что хранилище на этом хосте (или в этом кластере хранения, если используется сетевое SDS-хранилище, а не локальный NVMe) тоже переподписано.

Собираем методику: когда оверселлинг — норма, а когда — проблема

Три источника данных выше — steal time за несколько дней, почасовой CPU-бенчмарк, почасовой fio-тест — вместе дают куда более убедительную картину, чем ощущение «сервер тормозит». Обобщённо признаки стоит читать так:

Если по всем трём пунктам картина спокойная — вы, скорее всего, имеете дело с обычным, экономически обоснованным оверселлингом, который и позволяет тарифу стоить разумных денег: часть мощности хоста статистически не используется одновременно всеми арендаторами, и вы платите меньше именно за счёт этого. Это нормальная и честная модель, а не повод требовать возврат средств.

Если же данные за неделю стабильно показывают признаки из правой колонки — у вас на руках не ощущение, а конкретный лог с метками времени, с которым можно идти в поддержку хостинга (это звучит убедительнее, чем «у меня тормозит») или сравнивать с другим провайдером/тарифом. Если нагрузка чувствительна к задержкам (торговые терминалы, реального времени обработка, СУБД под нагрузкой) и цифры регулярно показывают конкуренцию за ресурс — экономический смысл переходить на тариф с гарантированным (dedicated) vCPU или на выделенный сервер, где переподписки по определению нет, потому что физическое железо не делится ни с кем.

Частые вопросы