Миф: гарантированное ядро и виртуальное — одно и то же

MAATRIX

Два тарифа в прайсе хостера обещают одинаковое «4 vCPU», но на одном сайт держит нагрузку стабильно, а на другом периодически замирает без видимой причины внутри вашей же виртуалки. Разница почти всегда в одном слове, которое легко пропустить в описании тарифа: «гарантированное» ядро — это не то же самое, что просто «виртуальное». Ниже — что физически стоит за этими словами, как уточнить у провайдера, что вы на самом деле покупаете, и как отличить нормальную виртуализацию от честного (или не очень) overselling.

Как звучит миф и откуда он берётся

Миф формулируется примерно так: «в тарифе написано 4 vCPU — значит, это четыре ядра, которые принадлежат мне, всегда доступны на все 100% и ничем не отличаются от четырёх ядер на выделенном сервере». Логика понятна: число одинаковое, слово «ядро» одинаковое, зачем вникать в детали.

Путаница закономерна ещё и потому, что сам термин vCPU изначально расплывчатый. Виртуальное ядро — это не кусок кремния, а планируемая сущность: поток исполнения, который гипервизор время от времени ставит на физическое ядро или аппаратный поток (thread) реального процессора. Сколько именно физических тактов достанется этому потоку в конкретную секунду — зависит от того, сколько ещё таких же виртуальных ядер конкурируют за то же самое физическое ядро на этом хосте. Маркетинговое «vCPU» в прайс-листе ничего не говорит о том, эксклюзивно ли оно ваше или разделено с соседями — это решается моделью размещения, которая часто прячется в мелком шрифте тарифа или вообще нигде явно не написана.

Отсюда и главная ошибка: сравнивать тарифы только по числу ядер и объёму RAM, не спрашивая, как это число реализовано на уровне гипервизора. Два тарифа с одинаковыми цифрами в характеристиках могут давать принципиально разный опыт под нагрузкой.

Что физически происходит с обычным (виртуальным) vCPU на хосте

На физическом сервере хостера стоит гипервизор — KVM, Xen или что-то ещё, механика похожая. У сервера есть конечное число физических ядер и потоков (посмотреть на своей стороне можно командой nproc или lscpu — но это число ваших *виртуальных* ядер, а не физических на хосте, увидеть которые изнутри VM обычно нельзя). На этом железе одновременно крутится множество виртуальных машин, и у каждой — свой набор vCPU-потоков, которые нужно куда-то поставить на исполнение.

Планировщик хост-системы (для KVM/QEMU это обычный планировщик ядра Linux, CFS) решает, чей vCPU-поток получит физическое ядро в следующий квант времени. Если суммарное число проданных vCPU на хосте превышает число физических ядер — а так происходит почти всегда, это и есть overselling (переподписка) — то в моменты, когда несколько VM одновременно требуют CPU, кому-то приходится подождать. Тому, кто ждёт, время недоступности физического ядра засчитывается как steal time — отдельная метрика, которую видно изнутри VM в vmstat/top в колонке %st. Подробно, как её читать и как отличить от обычной загрузки CPU, разобрано в статье steal time: как понять, что сосед по железу ест ваш процессор.

Важно: сама по себе переподписка — это не обман и не признак плохого хостинга. Это стандартная экономика виртуализации, похожая на овербукинг в авиакомпаниях: большинство нагрузок пульсирующие, редко кто использует свои vCPU на 100% постоянно, поэтому продавать больше vCPU, чем физических ядер, статистически разумно и позволяет держать цену ниже. Проблема начинается тогда, когда коэффициент переподписки завышен, а состав соседей на хосте оказывается «неудачным» — несколько тяжёлых нагрузок пересекаются по времени пиков. Про механику этого явления подробнее в статье где виртуализация теряет производительность.

Что технически означает «гарантированное» или «выделенное» ядро

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

• CPU pinning — конкретный vCPU-поток вашей VM жёстко привязывается к конкретному физическому ядру или потоку процессора (через taskset или встроенные механизмы гипервизора, например vcpupin в libvirt), и это физическое ядро не участвует в планировании для чужих VM. Это самый строгий вариант гарантии — ближе всего к «ядро физически ваше».
• Резервирование через cgroup-квоты — без жёсткого пиннинга, но с зарезервированной долей CPU-времени. В терминах cgroup v1 это cpu.cfs_quota_us/cpu.cfs_period_us, в cgroup v2 — единый файл cpu.max; провайдер настраивает лимиты и резервы так, чтобы даже при полной загрузке хоста ваша VM гарантированно получала оговорённую долю такта.
• Коэффициент переподписки 1:1 — на этом тарифе провайдер просто не продаёт больше vCPU, чем есть физических ядер на хосте, без явного пиннинга. Формально это тоже «без overselling», но при плохой реализации планировщика в моменты пиков возможны небольшие колебания.

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

Как уточнить у провайдера, что вы реально получаете

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

• Какой коэффициент переподписки (oversubscription ratio) используется на этом тарифе — 1:1, 2:1, 4:1 или другой? Провайдер может не публиковать точную цифру, но обычно готов сказать, попадает ли тариф в категорию «shared» или «dedicated/guaranteed».
• Как именно реализована гарантия — CPU pinning на физическое ядро/поток или резервирование через квоты cgroup без пиннинга? Это разный уровень изоляции, и для задач с жёсткими требованиями к задержке разница ощутима.
• Гарантия действует на весь тариф или это отдельная платная опция поверх обычного vCPU? Иногда «гарантированное ядро» — это апгрейд, который нужно явно заказать, а не свойство самого тарифного плана.
• Зафиксирована ли гарантия в SLA как измеримая метрика (например, минимальная гарантированная доля CPU-времени), или это только формулировка в маркетинговом описании без обязательств?
• Что происходит технически при пиковой нагрузке соседей по хосту — просядет ли ваша производительность, и если да, то в каких пределах?

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

Симптомы overselling: нестабильная производительность при низкой внутренней нагрузке

Главный диагностический признак того, что вы столкнулись с overselling на тарифе без реальной гарантии, — это нестабильная производительность, которая не объясняется вашей собственной нагрузкой. Классическая картина: top или мониторинг приложения показывают низкую загрузку CPU внутри VM, память свободна, очередей на диске нет, а запросы всё равно периодически выполняются заметно дольше обычного, будто процессор время от времени «пропадает».

Это именно тот случай, когда стоит смотреть на steal time, а не только на обычную загрузку CPU (us+sy). Высокий %st при низких us/sy означает, что вашему процессу физически не давали работать — ядро было занято чужой задачей на том же хосте, и никакая оптимизация кода эту просадку не уберёт. Пошаговая методика — как замерить это через vmstat 1, отличить от обычной нагрузки и как бенчмарком по часам суток поймать паттерн (например, просадки именно в вечерний пик, когда у соседей по хосту тоже растёт нагрузка) — подробно разобрана в статье оверселлинг в цифрах: как понять, что вам продали воздух.

Ещё один симптом — колебания результата одного и того же бенчмарка CPU (например, простого счётного теста) в разное время суток при том, что ваша собственная нагрузка не менялась. Стабильный тариф с честной гарантией даёт примерно одинаковый результат независимо от часа; тариф с агрессивной переподпиской — заметно разный. Похожая картина «шумного соседа» бывает не только с CPU, но и с диском и сетью — общая механика явления и как её опознать описана в статье шумный сосед на гипервизоре.

Отдельно стоит оговориться: разовый всплеск %st в течение нескольких секунд — это нормально почти на любом shared-тарифе, это не повод для паники или претензии в поддержку. Тревожный сигнал — устойчивый, воспроизводимый паттерн: %st регулярно поднимается в одни и те же периоды, коррелирует с ощутимыми задержками в приложении и не объясняется вашей собственной нагрузкой.

Когда гарантированное ядро оправдано, а когда это лишняя трата денег

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

Гарантированное ядро оправдано там, где чувствительность к задержке высокая и предсказуемая: real-time обработка, серверы для игр, базы данных с жёстким SLA по времени отклика, биллинговые и платёжные системы, где случайная просадка на секунды — это инцидент, а не мелкая неприятность. В этих сценариях переплата за гарантию — это не перестраховка, а часть требований к продукту.

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

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