На двух тарифах может быть написано одно и то же: 4 vCPU, 8 GB RAM, 100 GB NVMe. Но после переноса сайта или приложения новый VPS внезапно оказывается медленнее старого. Архив собирается дольше, страница генерируется медленнее, импорт идёт с паузами, а под нагрузкой появляются просадки.
vCPU не является единицей производительности. Число виртуальных процессоров не говорит, какой физический CPU установлен на узле, насколько он загружен, есть ли CPU quota, throttling или overcommit, какие ограничения действуют на диск и сколько процессорного времени реально получает виртуальная машина. Поэтому одинаковые строки в тарифной таблице ещё не означают одинаковую скорость. Сравнивать нужно поведение серверов под одинаковой нагрузкой.
4 vCPU означают, что гостевая система видит четыре виртуальных процессора, предоставленных гипервизором. Это не то же самое, что четыре выделенных физических ядра. Два VPS с одинаковым количеством vCPU могут работать на разных процессорах и по-разному делить физические ресурсы с другими виртуальными машинами.
Один сервер, например, может находиться на узле со старым Xeon, другой - на более новом EPYC. Даже если оба тарифа показывают четыре виртуальных ядра, производительность одного потока будет зависеть от архитектуры CPU, поколения процессора и политики распределения процессорного времени.
Модель CPU можно посмотреть командамиlscpuилиcat /proc/cpuinfo. Но и здесь есть ограничение: в зависимости от настроек виртуализации гостевая система может видеть реальную модель процессора, близкую к ней модель или виртуализированное название. Кроме того, отображаемая модель не показывает, какую долю процессорного времени фактически получает конкретный VPS. Поэтомуlscpuполезен как часть диагностики, а не как окончательный ответ.
Тактовая частота важна, но сравнивать разные процессоры только по GHz нельзя. 3,0 GHz на одном CPU и 3,0 GHz на другом не означают одинаковое количество выполненной работы за секунду.
На производительность влияют архитектура, поколение процессора, IPC, размер и организация кэша, boost-режим и характер самой нагрузки. Поэтому VPS с более низкой номинальной частотой иногда выполняет конкретную задачу быстрее сервера с формально более высоким числом GHz.
Для проверки лучше использовать один и тот же тест. Например, можно запуститьsysbench cpu runна обоих VPS и повторить его несколько раз. Ещё полезнее измерить реальную однопоточную операцию проекта: обработку одного тяжёлого запроса, архивирование одинакового набора файлов или другую воспроизводимую задачу.
CPU steal показывает время, когда виртуальная машина была готова выполнять код, но не получила физический CPU от гипервизора. Для VPS это полезный диагностический сигнал, особенно если торможения возникают периодически и не совпадают с ростом собственной нагрузки приложения.
В Linux steal time обычно отображается как%st. Посмотреть его можно через:
top;vmstat 1;mpstat -P ALL 1.Смысл имеет не единичный всплеск, а повторяемая связь между ростом steal и падением производительности. Если сайт замедляется и в тот же момент%stрастёт, стоит повторить тест несколько раз и проверить, сохраняется ли зависимость.
На практике важно поймать сам момент просадки. Если сайт уже снова работает нормально, аtopоткрыли только спустя несколько минут, показатель может быть почти нулевым и ничего не объяснить. Поэтому%stлучше наблюдать непосредственно во время воспроизводимой нагрузки.
Низкий%stне доказывает, что VPS ничем не ограничен. Могут действовать CPU quota, throttling и другие механизмы планирования. Узкое место также может находиться в диске, памяти, базе данных или самом приложении. Поэтому steal time нужно сопоставлять с другими метриками, а не использовать как единственный критерий качества узла.
Количество vCPU и гарантированное процессорное время - разные характеристики. Два VPS могут иметь по 4 vCPU, но один использовать shared CPU, а другой предоставлять более предсказуемый доступ к процессорным ресурсам.
В модели shared CPU физические ресурсы узла используются несколькими виртуальными машинами. Сам по себе такой подход не плох: для небольшого сайта, тестового сервера, dev-среды или бота shared CPU может быть вполне нормальным вариантом, особенно если нагрузка возникает короткими пиками.
При overcommit провайдер может назначить виртуальным машинам суммарно больше виртуальных CPU, чем физический узел способен одновременно обслуживать на полной нагрузке. Сам overcommit ещё не означает плохую производительность. Проблема появляется, когда несколько VPS одновременно начинают активно требовать процессорное время и конкуренция становится заметна в реальной работе.
VPS может видеть несколько виртуальных процессоров, но фактически иметь ограничения на доступное процессорное время. CPU quota задаёт рамки потребления, а throttling означает принудительное ограничение производительности при определённых условиях. Burst, если он предусмотрен инфраструктурой, позволяет временно получить больше процессорного времени при наличии свободных ресурсов узла, но такую скорость нельзя воспринимать как постоянно гарантированную.
Тарифы с выделенными или гарантированными CPU-ресурсами обычно выбирают для постоянной нагрузки, где важна предсказуемость. Но dedicated CPU не обязан быть быстрее любого shared VPS в каждой задаче: всё равно имеют значение модель процессора, производительность одного ядра и остальные компоненты системы.
Дополнительные vCPU чаще увеличивают количество задач, которые сервер может выполнять параллельно, а не автоматически сокращают время каждой отдельной операции. Поэтому переход с 4 на 8 vCPU не означает, что один PHP-запрос, SQL-запрос или импорт станет выполняться вдвое быстрее.
Если конкретная операция в основном последовательная или упирается в один поток, главным фактором может оказаться производительность одного ядра. Дополнительные vCPU заметнее проявят себя там, где действительно есть параллелизм: несколько PHP workers, несколько Docker-контейнеров, фоновые workers, parallel build или большое число одновременных запросов.
Проверять это лучше двумя тестами: отдельно измерить время одной тяжёлой операции и отдельно посмотреть throughput при нескольких одновременных задачах. Больше ядер и быстрее один запрос - не одно и то же.
Фраза "новый VPS медленнее, значит процессор хуже" часто уводит диагностику в сторону. Приложение может ждать диск, активно использовать swap, упираться в MySQL, очередь PHP-FPM, внешний API или сеть. В таком случае увеличение количества vCPU почти ничего не изменит.
Надпись NVMe не гарантирует одинаковую фактическую скорость двух VPS. На результат влияют конфигурация хранилища, конкуренция за ресурсы, latency и ограничения IOPS. Для проверки можно использоватьfio, но интенсивные дисковые тесты не стоит бездумно запускать на production-сервере.
Если сравниваются два VPS, параметры дискового теста должны совпадать: размер блока, глубина очереди, режим чтения или записи, размер тестового файла и длительность. Иначе сравнение IOPS или throughput мало что скажет. Для проверки лучше использовать отдельный тестовый файл и заранее понимать характер создаваемой нагрузки.
Состояние памяти можно проверить черезfree -hиvmstat 1. Если под нагрузкой растёт активность swap, а задержки приложения увеличиваются, причина может быть не в CPU.
Медленный SQL-запрос, нехватка PHP-FPM workers, ожидание удалённого API или очередь внутри приложения способны создать ощущение "медленного сервера". Если процессор простаивает, бессмысленно первым делом добавлять ещё два vCPU. Сначала стоит понять, чего именно ждёт приложение.
Сравнивать два VPS нужно одинаковой рабочей нагрузкой, в максимально одинаковом окружении и несколькими запусками в разное время. Сравнение двух разных сайтов на двух разных стеках почти ничего не говорит о серверах: одновременно меняется слишком много переменных.
По возможности должны совпадать ОС, версии PHP и базы данных, приложение, конфигурация, тестовые данные, кэш и набор работающих сервисов. Если сравнивается WordPress, лучше тестировать одну и ту же копию проекта, а не два разных сайта.
sysbench cpu run;sysbench memory run;fioс одинаковыми параметрами на обоих VPS;Синтетический benchmark нужен, чтобы изолировать отдельный компонент. Он не заменяет тест реального приложения, потому что одинаковый CPU score ещё не означает одинаковое время ответа WordPress, MySQL или Node.js.
Один прогон benchmark - это фотография, а не характеристика сервера. Запускать тест один раз и сохранять только лучший результат смысла мало. Если один и тот же VPS через несколько часов заметно проседает при той же нагрузке, для production это может быть важнее рекорда в первом запуске.
Полезно повторить измерения утром, днём и вечером. Для VPS часто важнее не максимальный результат, а разброс между повторными запусками: он показывает, насколько предсказуемо сервер ведёт себя во времени.
Что проверить | Чем проверить | Что ищем |
|---|---|---|
CPU model |
| Различия физической платформы |
CPU steal |
| Рост %st во время торможения |
CPU benchmark |
| Воспроизводимая разница CPU |
Memory |
| Нехватка памяти, swap |
Disk |
| Latency, throughput, IOPS |
Application | Реальная операция | Соответствует ли benchmark рабочей нагрузке |
Ни одна отдельная метрика не должна становиться окончательным диагнозом. Надёжнее сопоставить несколько измерений и посмотреть, повторяется ли проблема в одинаковых условиях.
CPU benchmark не равен скорости приложения. Geekbench илиsysbenchпомогают оценить процессорную часть,fio- поведение диска, но рабочий проект состоит не из benchmark-тестов. WordPress, MySQL, Node.js, Docker и файловые операции могут упираться в разные компоненты.
Еслиsysbenchзаметно быстрее на VPS A, а одна и та же страница WordPress генерируется на обоих серверах одинаково, CPU может не быть текущим ограничением. И наоборот, хорошие цифры CPU не помогут приложению, которое ждёт медленный диск или базу данных.
Benchmark отвечает только на тот вопрос, который ему задали. Поэтому синтетический тест стоит использовать для диагностики компонента, а решение о переносе проекта или смене тарифа принимать по результатам реальной рабочей нагрузки.
Если перед вами два предложения с 4 vCPU, 8 GB RAM и 100 GB NVMe, дополнительно стоит узнать тип виртуализации, модель или поколение CPU, shared или dedicated CPU, особенности хранилища, возможные лимиты IOPS, скорость сетевого порта, географию сервера и возможность быстро изменить тариф.
При сравнении тарифов имеет смысл учитывать и тип виртуализации. Даже если сравниваются виртуальные серверы на KVM, одинаковое количество vCPU само по себе не гарантирует одинаковую производительность: многое зависит от физического узла, доступного процессорного времени, ограничений и характера нагрузки.
Если провайдер предоставляет тестовый период или позволяет быстро сменить конфигурацию, перед переносом production-проекта можно провести одинаковый набор тестов и посмотреть, насколько стабильно сервер выполняет именно вашу нагрузку.
lscpuи учитывайте, что она может быть виртуализирована или скрыта.%stнепосредственно во время нагрузки.Симптом | Куда смотреть дальше |
|---|---|
CPU benchmark стабильно хуже | Физическая платформа, quota, модель предоставления CPU |
Производительность периодически проседает | %st, throttling, общая повторяемость проблемы |
CPU быстрый, приложение медленное | База данных, диск, память, PHP-FPM, сеть, внешние сервисы |
Одна задача не ускоряется после добавления ядер | Проверить, умеет ли она эффективно использовать несколько потоков |
При параллельных запросах сервер быстрее | Дополнительные vCPU могут давать преимущество именно в throughput |
Если два VPS имеют одинаковые цифры в тарифе, сравните их на одной и той же нагрузке, повторите измерения и найдите реальное узкое место. Количество vCPU описывает конфигурацию виртуальной машины, но само по себе не отвечает на вопрос, насколько быстро она выполнит конкретную задачу.
В новом году компания STC представила несколько моделей доступных проводных мышек для портативных и настольных
Аутсорсинг в управлении проектами помогает организациям сосредоточиться на задачах бизнеса, сократить затраты и
Определенно гарнитура HyperX Cloud Stinger впечатляет, прежде всего, не качеством своего звучания, а как раз
