Процессоры десятилетней давности против современных EPYC: что реально влияет на скорость VPS и почему

Вопрос «почему один VPS летает, а другой с такими же 4 ядрами и 8 ГБ постоянно дергается» обычно заканчивается спором про «жадного провайдера» и «неудачных соседей». Иногда это правда. Но чаще причина банальнее и одновременно сложнее: реальная скорость VPS определяется не количеством виртуальных ядер на бумаге, а архитектурой CPU, памятью, кэшами, вводом-выводом и тем, как гипервизор раздает ресурсы.

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

В этой статье разберем, чем VPS на процессорах десятилетней давности отличается от VPS на современных AMD EPYC на уровне физики вычислений и практики эксплуатации. Без маркетинга и без «магических твиков»: только то, что действительно влияет на время ответа, пропускную способность и стабильность под реальной нагрузкой.

Почему «одинаковые ядра» не означают одинаковую скорость

Виртуальное ядро (vCPU) не равно физическому ядру (pCPU) по смыслу. vCPU – это квота времени на выполнение инструкций, которую гипервизор должен выделить вашей VM. Если у вас «4 vCPU», это не обещание, что вы всегда получаете 4 полноценных физических ядра в монопольное пользование. Это обещание зависит от политики провайдера и от того, насколько плотно он упаковал виртуальные машины на узле.

Но даже если отвлечься от оверселинга и представить идеальную ситуацию «1 vCPU = 1 физическое ядро», сравнение старого и нового CPU все равно будет некорректным, потому что:

• разная микроархитектура дает разное число полезной работы на такт (IPC)
• разная организация кэшей и памяти меняет задержки доступа к данным
• разная платформа (память, шины, PCIe) меняет скорость I/O и стабильность p95
• разный набор инструкций и ускорителей влияет на шифрование, сжатие, сериализацию

Именно поэтому VPS на условном серверном CPU 2014-2015 годов и VPS на современном EPYC могут отличаться не на «проценты», а на ощущаемую категорию: один вариант держит пиковую нагрузку без хвоста задержек, второй начинает копить очередь и внезапно «тупить», хотя «CPU всего 40%».

IPC и частота: причина, почему «одно ядро» может быть в разы сильнее

Один из самых недооцененных факторов в VPS – однопоточная производительность. Большая доля прикладных систем имеет хотя бы один участок, который плохо параллелится: один воркер, один поток обработки очереди, один процесс БД на конкретной операции, блокировка в приложении, тяжелый запрос, который выполняется в одном потоке. В таких местах вас интересует не количество ядер, а сколько работы за секунду делает одно ядро.

На практике на скорость одного ядра влияют:

• IPC – сколько инструкций CPU способен выполнить за такт при типичной нагрузке
• частота и турбо – реальная частота на 1-2 активных ядрах и на всех ядрах
• предсказуемость турбо – держит ли процессор частоту стабильно или постоянно сбрасывает из-за лимитов

Хитрый момент: на VPS вы редко знаете, в каких режимах работает турбо на узле и как провайдер настроил энергопрофиль. Поэтому «частота в спецификации» – это только ориентир. Нужны измерения на ваших задачах и метрики хвоста задержек.

Характерный пример современного класса CPU: AMD EPYC 9845 имеет базовую частоту 2.1 ГГц и boost до 3.7 ГГц. Такие цифры важны не сами по себе, а как индикатор того, что под умеренной нагрузкой отдельные потоки могут выполняться значительно быстрее, чем на старых платформах, где турбо более скромное или менее стабильно.

Кэш и память: почему «быстро» – это часто про данные, а не про вычисления

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

Здесь есть два больших отличия современных платформ от старых:

1. Объем и организация L3 кэша
Большой общий L3 снижает число «дорогих» походов в оперативную память. Это особенно заметно на базах данных, кеширующих слоях, высоконагруженных API и даже на PHP/Node при большом количестве зависимостей и горячих путей кода. У современных EPYC L3 кэш измеряется сотнями мегабайт на сокет, и это напрямую бьет по tail-latency: редкие медленные запросы встречаются реже, потому что больше данных попадает в кэш.

2. Пропускная способность памяти и задержки
Переход от старых поколений памяти к DDR5 увеличивает пропускную способность, а в ряде сценариев улучшает и поведение под конкурентной нагрузкой. Важно понимать: «быстрее память» не всегда значит «быстрее один запрос», но почти всегда значит «лучше держим много параллельных запросов без деградации хвоста».

Если ваш сервис начинает «сыпаться» именно в p95 и p99 при росте конкурентности, часто проблема не в том, что «мало ядер», а в том, что данные не успевают попадать в кэши и память начинает проигрывать по задержкам.

NUMA и «невидимые» штрафы: почему два одинаковых VPS могут вести себя по-разному

На современных серверных платформах CPU – это не монолит, а сложная система с несколькими кристаллами, контроллерами памяти и топологией соединений. Для виртуализации это означает, что:

• VM может оказаться привязана к ядрам, которые ближе или дальше к конкретной памяти
• доступ к «чужой» памяти (remote NUMA) может быть ощутимо медленнее
• при миграции VM между узлами или при перераспределении ресурсов характеристики могут меняться

Это объясняет ситуацию, когда «вчера было нормально, сегодня стало хуже» без видимых причин. На старых платформах NUMA тоже был, но современные многокристальные CPU сделали топологию еще более значимой.

Вывод практический: когда сравниваете «старый CPU» и «новый EPYC», сравнивайте не «средний CPU usage», а время ответа приложения, очереди и хвосты задержек. Именно они чувствительны к NUMA и кэшу.

Виртуализация и «украденное время»: как гипервизор превращает хороший CPU в плохой опыт

Есть понятие, о котором редко говорят в рекламных описаниях, но которое отлично объясняет странные тормоза – CPU steal time, или «время, украденное гипервизором». Это доля времени, когда ваша VM готова выполнять код, но физическое ядро занято другими VM, и вы вынужденно ждете.

На Linux это видно в top как показатель st. Если steal time заметный под нагрузкой, вы можете получить парадокс: приложение тормозит, очередь растет, а CPU usage внутри VM не выглядит как 100%. Просто потому, что часть времени вам не дали выполнить работу.

Отсюда важный тезис про «скорость VPS»: современный CPU раскрывается только тогда, когда провайдер обеспечивает предсказуемое распределение ресурсов. Например, если используется модель гарантированных ресурсов без оверселинга, влияние steal time обычно ниже, а поведение под пиком стабильнее. Это одна из причин, почему два VPS на одинаковом «железе» могут ощущаться по-разному.

Кстати, это важно и для Windows-сценариев. Запросы «vps windows» и «vds windows» часто связаны с RDP и интерактивной работой, где человек ощущает не среднюю пропускную способность, а микрозадержки. Там steal time проявляется как «подлагивания» интерфейса, даже если формально ресурсов хватает.

Диск и PCIe: когда вам кажется, что CPU слабый, но виноват I/O

Еще одна ловушка: многие приписывают медленную работу VPS «плохому процессору», хотя реальная проблема – в дисковой подсистеме и задержках I/O. Старые серверы чаще оснащались более медленными SSD или даже HDD, использовали старые поколения PCIe и контроллеров. Современные узлы чаще строятся вокруг NVMe, где выигрыш особенно заметен на мелких операциях.

Что важно понимать:

• пропускная способность (GB/s) важна для больших последовательных операций
• латентность важнее для баз данных, очередей, множества мелких файлов
• стабильность p95 I/O важнее, чем рекорд на синтетике

Если у вас база данных, логирование, сбор метрик или очереди, то «быстрый CPU» без хорошего диска не спасет. Он просто быстрее упирается в ожидание диска. Поэтому связка «современный CPU + быстрый NVMe + адекватная память» дает не только скорость, но и предсказуемость.

Безопасностные патчи и скрытый «налог» на старых платформах

После серии уязвимостей класса Spectre/Meltdown и связанных с ними проблем спекулятивного выполнения индустрия получила неприятную реальность: часть защит реализуется на уровне ОС и гипервизора и может влиять на производительность, особенно в сценариях с частыми переходами между режимами и системными вызовами.

На практике эффект очень зависит от:

• поколения CPU и аппаратных механизмов снижения риска
• настроек гипервизора
• профиля нагрузки (много syscalls, много контекстных переключений, много сетевого I/O)

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

Что реально влияет на скорость VPS: короткий чек-лист без мифов

Если вам нужно объяснить самому себе или руководителю, за что вы платите при выборе современной платформы, полезно мыслить так:

• время ответа – насколько быстро выполняется типовая операция (и особенно p95)
• предсказуемость – насколько поведение стабильно при пиках
• однопоточная скорость – насколько быстро отрабатывают тяжелые последовательные участки
• параллельная скорость – сколько запросов в секунду вы держите без очередей
• кэш и память – помещается ли рабочий набор и как ведет себя система при конкурентности
• I/O – латентность диска и сети, стабильность p95 по вводу-выводу
• политика виртуализации – есть ли оверселинг, какова доля steal time

Если хотя бы два пункта из списка критичны для бизнеса, экономия на «старом CPU» часто оказывается мнимой: вы платите простоями, нервами и постоянной борьбой с хвостами задержек.

Как сравнить старую и современную платформу на своем проекте: протокол тестов на 60-90 минут

Синтетика ради синтетики не нужна. Нужен короткий, но дисциплинированный протокол, который покажет, где у вас реальные узкие места.

1. Зафиксируйте сценарий
   Один и тот же релиз приложения, одна и та же конфигурация, одинаковые данные или дамп, одинаковые параметры.
2. Снимите хвосты
   Для веба или API снимайте p95 и p99 по времени ответа. Среднее значение оставьте для отчета, но решения принимайте по хвостам.
3. Проверьте steal time
   Во время теста смотрите top и поле st. Если st растет, сравнение CPU превращается в сравнение политики размещения.
4. Разделите CPU и I/O
   Сделайте два прогона: один максимально CPU-bound (например, нагрузка на приложение без тяжелой базы), второй с включенной БД и реальными запросами.
5. Проверьте диск на латентность
   fio с профилем 4k random read/write и измерением latency даст больше, чем красивая цифра MB/s.

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

Кому действительно нужен современный EPYC, а кому хватит старой платформы

Современный CPU критичен, если у вас:

• нагруженный сайт, API или сервис с требованиями к p95
• база данных, чувствительная к задержкам памяти и диска
• CI/CD, сборки, компиляция, где важна производительность на поток и на параллель
• шифрование, VPN, TLS, где ускорители и архитектура дают ощутимый эффект
• Windows Server и интерактивные сценарии (RDP), где заметны микрозадержки

Старой платформы иногда достаточно, если:

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

Но даже в «простых» случаях помните: скорость VPS – это не только «быстрее/медленнее», а еще и риск непредсказуемости. На старых узлах вы чаще сталкиваетесь с сюрпризами по диску, по турбо, по соседям, по хвостам. И эти сюрпризы редко видны по среднему CPU.

Вывод: процессор важен, но выигрывает тот, кто меряет хвосты и выбирает предсказуемость

Сравнение «CPU десятилетней давности» и современных EPYC в контексте VPS нельзя свести к одной цифре в бенчмарке. Реальная скорость VPS складывается из архитектуры CPU (IPC, турбо), кэшей и памяти, платформы I/O и политики виртуализации. Именно поэтому один и тот же проект на старой платформе может демонстрировать странные «затыки» и деградации по p95, а на современной – держать нагрузку ровнее, даже если формально «ядра те же».

Если подходить инженерно, решение простое: измеряйте время ответа и хвосты, проверяйте steal time, разделяйте CPU и I/O, и выбирайте конфигурацию под свой профиль нагрузки. Тогда выбор виртуального сервера перестает быть лотереей и превращается в расчет.