Давайте дружить в Телеграме: рассказываем про новые фичи и общаемся в комментах Подписаться
support@serv.host
Личный кабинет

Выбор Хостинга. Как хостеры оверселят VPS — и как проверить, что вам реально дали ресурсы

Как хостеры оверселят VPS — и как проверить, что вам реально дали ресурсы

Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему

**Сторонний мой проект: Zapret2UI.


Вы взяли тариф «4 vCPU / 8 ГБ / 60gb NVMe»/ или любой другой, заплатили, а оно почему-то подтормаживает, долго грузит и т.д:apt думает, сайт «плавает» по скорости в зависимости от времени суток, ssh иногда залипает. Если Вам данная информация о чем-то говорит, то почти со 100% вероятностью то, что я напишу здесь - поможет Вам понять причину всей этой бредятины или же.

Как хостеры обманывают самых маленьких продавая воздух(буквально)

Важно учитывать, что в основном это касается лоукост хостингов(100-300руб. = $1.5-3), но так же нужно понимать, что и крупные хостинги грешны таким

Часто это не ваш кривой софт, а оверселлинг — когда на одной физической железке живёт больше виртуалок, чем она реально тянет, и вы делите ресурсы с шумными соседями, которые решают сверлить всегда, ремонт который идет 10 лет, все мы через это проходили.

Хорошая новость: почти всё это проверяется за полчаса стандартными утилитами. Ниже — что и как оверселят, какими командами это ловится по каждому ресурсу (CPU, RAM, диск, сеть) и что делать, если вас поймали на горячем.

Кому пригодится: если арендованный VPS кажется медленнее, чем должен; если выбираете хостера и не хотите нарваться; или если просто хотите научиться проверять сервер «по-взрослому», а не на глаз и на вере.

Дальше — и по-простому на аналогиях, и технически с командами, которые можно копировать и запускать. Кому нужен только план действий — листайте в чеклист.


Содержание

  1. Что такое оверселлинг и зачем хостеры это делают
  2. Что именно оверселят
  3. Первые звоночки — без бенчмарков
  4. Проверяем процессор и steal time
  5. Проверяем оперативную память
  6. Проверяем диск
  7. Проверяем сеть
  8. KVM или OpenVZ — и почему это решает
  9. Чеклист первого часа на новом VPS
  10. Что делать, если вас оверселят
  11. Как выбрать VPS, где не душат
  12. Короткий итог

Источники и инструменты


Что такое оверселлинг и зачем хостеры это делают

Оверселлинг (он же overcommit, оверсабскрипшн) — это когда хостер продаёт больше ресурсов, чем физически есть на сервере, в расчёте на то, что все клиенты разом на 100% их не используют.

Аналогия — фитнес-клуб(согласен, возможно звучит глупо, но скоро вы меня поймете). В зале 200 тренажёров, но абонементов продано 5000. Расчёт простой: все разом не придут. Пока это так — всем норм и абонемент дешёвый. А вот 1 января, когда полгорода ринулось «с понедельника новая жизнь», внезапно очередь на беговую дорожку. Ваш VPS — та же беговая дорожка, а соседи по ноде — те самые новогодние энтузиасты.

И вот что важно понять сразу: лёгкий оверселлинг — это норма индустрии, а не преступление. Средний VPS простаивает на 5–10% нагрузки, и если бы хостеры не уплотняли — цены были бы в разы выше.

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

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

Граница простая:

  • Норм: вы платите мало, изредка ловите микро-просадки в час пик, в целом всё летает. Это честная сделка.
  • Не норм: steal висит на 25%, диск отвечает как через болото, а «4 ядра» по факту тянут как полтора. Вот тут вам впарили воздух.

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


Что именно оверселят

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

РесурсКак оверселятЧем это грозит вам
CPU (vCPU)Много виртуальных ядер на одно физическое (4:1, 8:1 и хуже)Тормоза под нагрузкой, высокий steal
RAM«Бурстовая» память, KSM-дедупликация, balloon-драйверСвоп, тормоза, в худшем случае OOM (убийство процессов)
Место на дискеThin provisioning — суммарно «продано» больше, чем естьРиск «внезапно места нет» сразу у всех
Диск IOPSОбщий пул операций на всю нодуМедленные чтения/записи, высокий iowait
СетьОбщий аплинк, узкий канал «на этаж»Просадки скорости в час пик, «безлимит» с троттлингом

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


Первые звоночки без бенчмарков

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

  • Load average против числа ядер. Смотрим uptime (или cat /proc/loadavg) и сравниваем с nproc. Если сервер почти простаивает по вашим процессам, а load стабильно выше числа ядер — кто-то отъедает CPU мимо вас.
  • top / htop, колонки st и wa. %st (steal) — сколько вашего процессорного времени «украл» гипервизор под соседей. %wa (iowait) — сколько система простояла в ожидании диска. Высокий st — беда с CPU-соседями, высокий wa — с диском.
  • OOM в логах. dmesg -T | grep -i -E 'oom|killed process' — если ядро отстреливало процессы из-за нехватки памяти, это прямой сигнал, что с RAM туго.
  • Ощущения по времени суток. Утром летает, вечером колом — классика перегруженной ноды в часы пик.

Это только наводки. Какие-то аномальные значения, конечно же покажут, что беда есть и где её можно найти, но это не то же самое. Дальше меряем цифрами.


Проверяем процессор и steal time

Steal time — главный индикатор

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

Аналогия: вы в очереди к одной кассе с соседями. Steal — это сколько вы простояли, пока кассир пробивал товар не вам. Пусто в очереди — steal около нуля. Толпа соседей — стоите и нервничаете.

Смотрим в динамике:

vmstat 1 10           # колонка st справа — смотрим под нагрузкой и в простое
mpstat -P ALL 2 5     # %steal по каждому ядру (пакет sysstat)

Как читать цифры (грубые ориентиры):

  • 0–2% — норма, живём спокойно.
  • 3–7% — звоночек, приглядитесь, померьте в разное время суток.
  • 10%+ стабильно — нода перегружена, вас душат соседи.
  • 20%+ сутками — откровенный оверсел, идём писать в поддержку.

Важный нюанс: steal честно виден на KVM. На OpenVZ/LXC (контейнеры) он не показателен — там уплотнение работает иначе, об этом в разделе про виртуализацию.

Сколько реально «лошадей» под капотом

Steal показывает загрузку соседями, но не саму мощность ядра. Меряем мощность бенчмарком и сравниваем с обещанным:

# однопоточный тест (чистая мощность одного ядра)
sysbench cpu --cpu-max-prime=20000 --threads=1 run

# все ядра разом
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

# альтернатива — архиватор 7-Zip, даёт рейтинг в MIPS
7z b

Смотрим events per second у sysbench или общий рейтинг у 7z b и повторяем замер несколько раз в разное время. Если днём цифры одни, а вечером проседают вдвое — это и есть оверсел в действии (мощность «плавает» под соседями).

Заодно проверьте, какой процессор вам вообще дали(да, такое тоже встречается):

lscpu
grep 'model name' /proc/cpuinfo | head -1

Если в оффере обещали свежий EPYC/Xeon, а по факту стоит древний E5 v2 — это уже повод для вопросов, даже без всякого steal.

Важное для каждого. В большинстве своем хостинги могут просто ошибиться, поэтому рекомендую собирать вопросы, которые у вас возникают при использовании серверами и позже приходить с фактами и фотками/логами того, что у вас происходит. Вам в 90% хостингов помогут(если это возможно).

Ловушка с cgroup-лимитом

Хитрый момент: nproc может показывать 8 ядер, но по факту вас режет квота cgroup (так делают на некоторых «облачных» и контейнерных тарифах). Проверяем реальный лимит:

# cgroup v2 (современные системы)
cat /sys/fs/cgroup/cpu.max
# вывод "200000 100000" = потолок 2 ядра; "max 100000" = без лимита

# cgroup v1
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us
cat /sys/fs/cgroup/cpu/cpu.cfs_period_us

Если quota / period меньше числа «видимых» ядер — вам показали больше, чем разрешают использовать.


Проверяем оперативную память

Сначала — сколько дали:

free -h
cat /proc/meminfo | head -5

Но «видно в free» и «реально ваше» — это не одно и то же. Память бывает бурстовой: показывают одно, а под нагрузкой отберут. Поэтому память надо не смотреть, а потрогать — реально занять и обратиться к каждому байту:

# занять и «пощупать» 90% RAM на минуту (пакет stress-ng)
stress-ng --vm 1 --vm-bytes 90% --timeout 60s --metrics-brief

# параллельно во втором окне следим за свопом
vmstat 1

Что должно насторожить во время теста:

  • Ненулевые и растущие si/so в vmstat — система засвопила, то есть реальной RAM меньше, чем нарисовано, и вас спасает медленный своп.
  • Сообщения OOM в dmesg — память кончилась раньше, чем вы «заняли» обещанный объём.

Своп — это технология линуха, что-то типо файла подкачки, которую можно задействовать заместо своей быстрой оперативной памяти, жесткую(ссд,хдд, диски крч) если Вам прям чуть чуть не хватает для нормального использования сервера, а обновляться по тарифу дорого, то в вполне может быть неплохим решением

Дополнительно стоит глянуть:

# есть ли balloon-драйвер — хост может «сдувать» вашу RAM по требованию
lsmod | grep -i balloon

# лимит памяти в cgroup
cat /sys/fs/cgroup/memory.max            # v2
cat /sys/fs/cgroup/memory/memory.limit_in_bytes   # v1

# на OpenVZ — реальные лимиты и счётчики отказов
cat /proc/user_beancounters

virtio_balloon сам по себе не зло (стандартная технология KVM), но его наличие означает, что память не полностью «прибита» за вами. А в /proc/user_beancounters (если он есть — вы на OpenVZ) смотрите колонку failcnt: значения больше нуля = вы уже упирались в лимиты, и система вам отказывала.


Проверяем диск

Место проверяется тривиально:

df -h
lsblk

Но оверселят обычно не место, а скорость диска — IOPS (операций в секунду) и латентность. Именно они превращают «NVMe из оффера» в тормозной SSD, который по бумажке огонь, а по факту банально хуже в работе.

Правильный инструмент — fio. Гоняем случайное чтение и запись мелкими блоками (это самый показательный и самый тяжёлый для оверсела режим):

# случайное чтение 4K
fio --name=randread --ioengine=libaio --iodepth=64 --rw=randread \
    --bs=4k --direct=1 --size=1G --numjobs=4 --runtime=30 --group_reporting

# случайная запись 4K (осторожно на проде — создаёт файл)
fio --name=randwrite --ioengine=libaio --iodepth=64 --rw=randwrite \
    --bs=4k --direct=1 --size=1G --numjobs=4 --runtime=30 --group_reporting

Смотрим строку IOPS= и латентность (lat). Ориентиры:

  • Настоящий локальный NVMe — десятки, а то и сотни тысяч IOPS на 4K.
  • SATA SSD — тысячи–десятки тысяч.
  • Если за «NVMe» вам выдают 1–3 тысячи IOPS — вам либо впарили сетевое хранилище под видом локального, либо жёстко порезали лимит.

Быстрая грубая прикидка без fio (менее точная, но пойдёт для первого впечатления):

# запись с синхронизацией
dd if=/dev/zero of=test.bin bs=1M count=1024 oflag=dsync
# чтение
dd if=test.bin of=/dev/null bs=1M
rm test.bin

И отдельно — латентность, она выдаёт сетевое хранилище с потрохами:

ioping -c 20 .

Локальный NVMe отвечает примерно за 0,1–0,3 мс и стабильно. Если видите 2–5 мс и цифры скачут — под вами почти наверняка сетевой массив или перегруженная нода.

Не насилуйте чужой дисковый массив часами — это и против правил, и бьёт по соседям (не будьте тем самым душнилой). Пары коротких прогонов (5-15 мин) в разное время суток достаточно. И приберите за собой тестовые файлы.


Проверяем сеть

Тут два вопроса: какая реальная полоса и держит ли она нагрузку в час пик.

Меряем пропускную способность через iperf3 до сервера с заведомо толстым каналом (в идеале — тестовый сервер хостера, либо публичный из списка iperf.fr; учтите, что публичные бывают загружены):

iperf3 -c <адрес_сервера> -t 20        # отдача (upload)
iperf3 -c <адрес_сервера> -t 20 -R     # приём (download)
iperf3 -c <адрес_сервера> -t 20 -P 8   # 8 потоков — «выжать» канал

Более «жизненный» замер — обычный спидтест Ookla:

speedtest        # CLI от Ookla, которое можно установить

Заявленную скорость порта можно глянуть напрямую, но с оговоркой:

ethtool eth0 | grep Speed

На виртуальных сетевых картах (virtio) ethtool часто показывает 10000Mb/s или Unknown — это виртуальное значение, а не гарантия, так что верьте реальному замеру iperf3, а не этой строчке.

И два практических момента:

  • Час пик. Многие «безлимитные» тарифы прекрасно летают ночью и вязнут вечером. Гоняйте тесты в разное время, крупный файл — несколько минут подряд, чтобы поймать троттлинг после первых гигабайт.
  • Качество маршрута, а не только скорость: mtr -rw <цель> покажет потери и пинг по каждому хопу — иногда проблема не в полосе, а в кривом аплинке до нужных вам регионов.

KVM или OpenVZ и почему это решает

Тип виртуализации напрямую определяет, насколько легко вас оверселить и насколько честно это вообще видно изнутри.

KVMOpenVZ / LXC
ТипПолная виртуализацияКонтейнер (общее ядро с хостом)
RAM«Настоящая», выделеннаяЧасто бурстовая, оверселят агрессивнее
Steal виденДа, честноПлохо показателен
free/topГоворят правдуМогут вводить в заблуждение
Склонность к оверселуУмереннаяВысокая
Как определитьlscpu → Hypervisor vendor: KVMналичие /proc/vz, /proc/user_beancounters

Определяем, что нам досталось:

systemd-detect-virt      # kvm / openvz / lxc / none (выделенный/dedicated)
hostnamectl | grep Virt   # строка Virtualization
lscpu | grep -i hypervisor
ls /proc/vz 2>/dev/null && echo "похоже на OpenVZ"

Это не значит, что OpenVZ — однозначно зло: он дешевле и для нетребовательных задач нормально. Но под что-то важное (базы, продакшн, VPN-нода, из-за которой всё и затевалось) берите KVM, а ещё лучше — тариф с явно выделенными (dedicated) vCPU. Там оверсела по определению меньше, а статистика и метрики честнее.


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

Прогоните это сразу после выдачи сервера — и вы будете точно знать, что купили. Сохраните вывод (логи, скриншоты): пригодится, если придётся спорить с поддержкой.

  1. Что за виртуализация: systemd-detect-virt, lscpu | grep -i hypervisor
  2. Что дали: lscpu, free -h, df -h, grep 'model name' /proc/cpuinfo
  3. Steal в простое и под нагрузкой: vmstat 1 10, mpstat -P ALL 2 5
  4. Мощность CPU: sysbench cpu ... run (1 поток и $(nproc)), 7z b
  5. Пощупать RAM: stress-ng --vm 1 --vm-bytes 90% --timeout 60s + vmstat 1
  6. Диск: fio (randread/randwrite 4K), ioping -c 20 .
  7. Сеть: iperf3 -c ... -R -P 8, speedtest, mtr -rw <цель>
  8. Повторить вечером в час пик — оверсел проявляется именно под общей нагрузкой.

Как установить всё одной командой (Debian/Ubuntu):

sudo apt update && sudo apt install -y \
  sysstat sysbench fio ioping stress-ng iperf3 p7zip-full ethtool mtr-tiny

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


Что делать, если вас оверселят

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

  1. Соберите доказательства. Несколько замеров в разное время: логи steal, вывод fio, iperf3, скриншоты htop. Одна вечерняя цифра — слабый аргумент, а сутки графиков — сильный.
  2. Напишите в поддержку конкретно. Не «у меня тормозит, что-то грузит долго», а «steal держится 25% сутки, fio 4K randread даёт 1500 IOPS при заявленном NVMe, вот логи. Прошу разобраться или перенести на другую ноду». Конкретика с цифрами работает, потому что если вы идете к ним с прямыми замерами - им некуда деваться, банально они нарушили то, что заявляли(обещали продать).
  3. Просите перенос на другую ноду — часто проблема локальна, и переезд решает всё. Хорошие хостеры делают это без вопросов, при малейших проблемах это возможно, если есть на это основания.
  4. Перечитайте оффер. Если там честно написано «shared/burstable» — формально хостер прав, и это урок на будущее. Если обещали «dedicated vCPU / гарантированные ресурсы» — держите за слово.
  5. Не помогло — голосуйте кошельком. Тестовый период, возврат средств, переезд к другому. Плюс честный отзыв с цифрами — другим пригодится. Думаю что самое хорошее — это возможность оставлять честные отзывы, пожалуйста, не забывайте этого делать, так вы помогаете хорошим хостингам стать ещё лучше, а плохим утонуть и закрыться навсегда. Чаще всего это их изначальный выбор что же они будут делать, деньги или сервис.

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


Как выбрать VPS, где не душат

Признаки хостера, который не жадничает:

  • KVM (а не только OpenVZ) и наличие тарифов с выделенными vCPU.
  • В оффере конкретные цифры: гарантированные IOPS, скорость порта, модель CPU — а не только «быстрый NVMe» и «мощные процессоры».
  • Тестовый период или почасовая оплата — можно взять, прогнать весь чеклист выше и соскочить, если не понравилось.
  • Живые отзывы с техникой: ищите в обзорах слова steal, iops, fio — там, где люди меряли, а не просто «мне норм» и получали за это баланс внутри сервиса (очень распространено).

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

Красные флаги: подозрительно дёшево за много ядер, «безлимит» без единой оговорки, только OpenVZ, нет никакого тестового периода.

Где поднять и сразу проверить. Удобно, когда хостер не мешает вам себя же протестировать. Например, на serv.host — KVM, выделенные ресурсы, чистые IP и стабильная полоса; берёте сервер и первым делом прогоняете весь чеклист из этой статьи, чтобы убедиться в цифрах, а не верить на слово.

Честно про эту индустрию: любой хостер немного оверселит — без этого VPS стоили бы кратно дороже. Выбирать надо не «того, кто не оверселит вообще» (таких почти нет за вменяемые деньги), а того, кто делает это аккуратно и не мешает вам проверить, что вы получили.


Короткий итог

  • Оверселлинг — норма, жадный оверселлинг — беда. Задача не в том, чтобы найти «идеального» хостера, а в том, чтобы уметь померить и отличить одно от другого.
  • Три главные проверки: steal (CPU), fio + ioping (диск), iperf3 (сеть). Память — потрогать через stress-ng. Тип виртуализации — systemd-detect-virt.
  • Мерьте в час пик и повторяйте. Оверсел — это про поведение под нагрузкой во времени, а не про одну красивую цифру ночью, иначе вы можете лишь убедиться в том, всё отлично, хотя это не обязательно так, особенно у лоу кост хостеров.
  • Держите логи — с ними поддержка чинит проблему в разы охотнее, чем с «у меня всё тормозит».
  • Ресурсы критичны — платите за dedicated. Дешёвый шаред хорош, пока сосед ведёт себя тихо; для важного берите гарантированные ресурсы и KVM.

Полчаса тестов на старте экономят недели догадок «мне кажется или правда медленно». Теперь — не кажется, а знаете точно, проверяйте то, что планируете использовать.


Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему

**Сторонний мой проект: Zapret2UI.

Ну вообще вроде чуть полезно вышло, давайте не болейте там, всех благ


Источники и инструменты

Опять что-то вроде рекомендаций к прочтению, тоже английский там блин(легкий)