Direct answer

Virtualization itself is not a diagnosis. A Minecraft server on a VM can run well, but shared host CPU time, constrained memory and shared storage may add unpredictable delay. Identify which resource is actually constrained.

Diagnose inside the VM

  1. Capture /spark tps and a profile while players notice delays. Save player count and time of day.
  2. On Linux, inspect top for CPU steal percentage, free -h for memory/swap, and df -h for capacity.
  3. Where systemd/cgroup v2 applies, read cpu.max and cpu.stat; a quota-induced throttle is not the same issue as CPU steal.
  4. Check backup jobs or other VMs that coincide with I/O stalls.

Interpret and fix

If CPU steal spikes, ask your provider about contention or dedicated allocation. If the game thread is costly even without steal, use the profiler to find entity, chunk or plugin work. If swap or disk latency is the issue, increase appropriate headroom or change the workload; adding virtual CPUs alone may not help.

Version and safety notes

The host may conceal underlying CPU allocation and noisy neighbors. For diagnosis, compare repeatable symptoms and escalate unexplained host-side contention to the provider.

Validation

Retest with a comparable player load at different host-busy periods. Record median and worst-case tick time before choosing a new hosting tier. Avoid running storage stress tests on a production world.

References

Check documentation for the versions and hosting environment you actually run.