New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Is it true that a VPS uses 10-35% more host CPU resources than is reported from within the VPS?
If something like monitorix or hetrixtools shows an average cpu use of 20% the VPS is actually consuming 30-55% on the host? Seems excessive.
Is KVM worse than other hypervisors in this regard?
How would you know how much actual CPU resources your VPS is using?
When a provider like Hosthatch (as an example) says on a 4 core VPS that you can use dedicated 100% of one core. That would be 25% of the total 4 cores. How is that 25% measured?
Comments
HostHatch’s dedicated term is a bit misleading. 4 vcores with 1 dedicated mean you are able to stay at 25% cpu usage 24/7. And the remaining 75% are burstable meaning you can only use that 75% in a short period of time
Yes, KVM virtualization introduces overhead at the hypervisor level, which your VM cannot directly observe.
The impact of this overhead depends on the activities within your VM and the hypervisor's configuration. For instance, using a software-emulated NIC or disk driver and handling many packets or I/O operations per second will consume significantly more host resources compared to using a driver with better hardware acceleration, like VirtIO.
It's common for VMs to be placed within cgroups, which restrict their resource usage to the allocated amount. For example, if you purchase 1 vCPU, your VM's cgroup will allow up to 100% of the vCPU, including overheads. This overhead will appear as 'steal time' within your VM.
Overhead for modern hardware is almost zero.
Well, yes and no. We've had technologies like SR-IOV and vIOMMU for many years now, though they're rarely configured properly if at all, especially on low-end hosts. There are things that we simply can't virtualize cost-effectively like GPU, even if just for basic console, and we'll always have CPU overhead for interrupts outside of disk and network. Despite modernized instruction sets and CPU features over the last say 10 years, there's little difference in overhead, but of course, performance per clock continues to advance.
There is a ton of cpu power, very often under utilized. Gen4 nvme which is almost a RAM with peristency. And of course there is DDR5 with frequencies going above cpu frequency. And virtualization software core is still dated back, when optimization mattered. So, slam threadripper, jam ddr5 and sprinkle some nvme with juicy 100gbit card pair. You are good to go…
Hey there! It sounds like you're noticing some discrepancies between the CPU usage reported by tools like Monitorix or Hetrixtools inside your VPS and what's actually happening on the host. This is pretty normal due to virtualization overhead. Every hypervisor, including KVM, adds a bit of extra work to manage virtual machines, which can make the actual CPU use on the host higher than what you see in your VPS.
When HostHatch says you get 100% of one core on a 4-core VPS, that's like saying you have 25% of the total CPU power, but that's just for your VPS. On the host, this might look different because of how the hypervisor handles resources. To really get a sense of how much CPU your VPS is using on the host, you'd need host-level insights, which providers usually don't share directly with users.
Just remember, KVM's performance is generally good, but there's always some overhead with virtualization.
We installed QEMU on a dedicated server to do networking experiments.
The workload inside the guest OS is IP packet forwarding with some header manipulation performed in a kernel module.
When we inject enough traffic to saturate the 1-core VM to use 100% guest CPU:
Hence, for I/O heavy workloads, it's possible to consume more CPU than what's observable within the guest OS.
kernel has steal time accounting but is not compiled in by default in most distrubitions to avoid even more overhead.
I mean, sure. If you run a basic Linux bridge, basic VirtIO and vhost-net, zero tuning, and no SR-IOV, you're going to chew through CPU cycles on the hypervisor for the NIC and bridge. Those are a given, and not really relevant to the "VM" overhead per se. Very little of that would fall within the cgroup, even if it were contained.
You can go far by performance-tuning VirtIO and vhost-net on the hypervisor. Though, of course, SR-IOV and a decent NIC will get you cooking on gas with very little hypervisor CPU overhead.
One can ask HH support to keep only dedicated vCore and discard burst vCores. And then 100% usage of that 1 dedicated vCore works.