Each vCPU maps to one physical thread reserved for you. Memory and disk are not shared. It behaves like a dedicated server, at a fraction of the cost.
Automatic activation. No setup fee. 7-day guarantee.
Common practice in this market is to sell two or more vCPU for every real thread on the processor. It works on average, and it is what keeps a regular VPS affordable. The problem shows up at peak: when several machines on the same host ask for CPU at the same time, yours gets in line.
On the Virtual Dedicated Server that ratio is one to one. The node is not oversold: the sum of the vCPU sold never exceeds the number of physical threads on the processor. Your tick does not depend on what the neighbor decided to run at nine in the evening.
It is the difference between having CPU available and having CPU guaranteed.
If any of these scenarios is yours, 1:1 allocation changes the outcome.
Above 200 players the main thread of the server starts running close to its limit during almost every peak hour. In that range, the difference between a guaranteed core and a contended core shows up directly in the tick rate and in the lag reports coming from players.
Anyone running several SA-MP, MTA or FiveM instances on one machine needs predictable cores, because each instance takes one. With shared CPU, the bottleneck moves from instance to instance with no pattern and diagnosing it turns into trial and error.
If your usage graph lives above 70% and you have already ruled out a code problem, the next step is not more shared vCPU. It is vCPU that does not compete.
PostgreSQL, MySQL, Redis and processing queues suffer more from variation than from averages. Reserved threads and exclusive NVMe keep response time steady in the high percentiles, which is where the end user notices it.
The jump from a top-end VPS to a dedicated server is more than two and a half times. The Virtual Dedicated Server exists for the operator who has outgrown the first and does not yet need the second.
Every provider that sells VPS picks a ratio between vCPU sold and physical threads available. Once that ratio goes past one to one, two machines can want the same thread at the same instant. One runs, the other waits.
That waiting time has a name, and it shows up in your own system. It is steal time, reported as %st in top and as the st column in vmstat 1. It measures how long your vCPU wanted to process and could not, because the hypervisor handed the thread to another virtual machine.
The detail that misleads people is that the average looks fine. Under normal use the contention is rare and steal time sits near zero, so the graph on the dashboard looks healthy all month. The pain happens at peak, which is exactly when your server is full and your community is online. That is why so many people describe the problem as an occasional stutter instead of constant slowness.
Run vmstat 1 on your current server at peak hour and watch the st column. If it climbs consistently, you do not have a plan size problem. You have a CPU contention problem, and adding RAM will not solve it.
With 1:1 allocation there is no other machine competing for your threads, so steal time stays at zero even with the machine under load.
The node never takes more vCPU than it has physical threads, so yours never queue behind another customer. Run vmstat on your current server at peak hour and compare the st column with the one here.
Daily snapshot on separate storage, with 7-day retention. Restore from the panel or by ticket. We do not charge for it separately.
The server is already in the rack. You sign up, get the credentials in minutes and bring your stack up the same day. A brand new dedicated machine takes up to 48 hours to reach production.
When memory gets tight, moving to a full dedicated server has no fee. We move the data and you pay only the difference.
Automatic activation, no setup fee, with a 7-day guarantee.