Stop Using OpenVZ for Production: Why KVM is the Only Sanity-Saving Choice for High-Load Systems

It’s 3:00 AM on a Tuesday. Your monitoring system—Nagios, if you’re sensible—is screaming. Your MySQL slave is lagging, and Apache is dropping connections. You SSH in, run top, and see... nothing. Your Load Average is 0.5. Your CPU usage is 10%. Yet, your application is crawling.

If you are hosting on a budget VPS provider using OpenVZ or Virtuozzo, you aren't fighting your code; you are fighting your neighbors. In the world of high-availability hosting, the hypervisor you choose is just as critical as the database schema you design. Let's cut through the marketing fluff and talk about why Kernel-based Virtual Machine (KVM) is the only serious choice for production workloads in 2012.

The "Burst RAM" Lie

OpenVZ relies on a shared kernel. It uses a resource management system (User Bean Counters) to limit what you can use. Providers often oversell this aggressively, offering "Burst RAM" that doesn't physically exist. When the host node runs out of real memory, the kernel invokes the OOM (Out of Memory) killer. It doesn't kill the heavy neighbor; it often kills your MySQL process because it happens to be requesting memory at that exact second.

With KVM (Kernel-based Virtual Machine), the virtualization happens at the hardware level using Intel VT-x or AMD-V extensions. If you are allocated 4GB of RAM on a CoolVDS KVM instance, that RAM is reserved for your OS. The host kernel doesn't just promise it; it walls it off.

Diagnosing "Steal Time": The Silent Killer

On a shared kernel environment, you have no visibility into the host's load. However, you can detect CPU contention. Run top and look at the %st (steal time) column.

Cpu(s):  2.0%us,  0.5%sy,  0.0%ni, 90.0%id,  0.2%wa,  0.0%hi,  0.0%si,  7.3%st

If %st is consistently above 0.0, the hypervisor is stealing CPU cycles from your VM to serve another customer. On budget OpenVZ hosts, I've seen this hit 50% during peak hours. That means your server is running at half speed, and there is absolutely no configuration change you can make to fix it.

Disk I/O and the Scheduler War

Here is where the battle is lost. In a container (OpenVZ/LXC), you generally cannot change the I/O scheduler. You are stuck with whatever the host uses—usually CFQ (Completely Fair Queuing), which is terrible for databases.

On a KVM instance, the disk appears as a block device (e.g., /dev/vda). You have full control. For a MySQL or PostgreSQL server, you want the Deadline or Noop scheduler to reduce latency. On CoolVDS KVM instances, we expose raw block devices, allowing you to tune this instantly:

# Check current scheduler
cat /sys/block/vda/queue/scheduler
[cfq] deadline noop

# Switch to deadline (run this at runtime)
echo deadline > /sys/block/vda/queue/scheduler

Make this permanent by editing /boot/grub/menu.lst (for CentOS 5/6) or /etc/default/grub (for newer Ubuntu 12.04 builds coming soon) and adding elevator=deadline to your kernel parameters.

Pro Tip: If you are running high-transaction databases, ensure your provider offers SSD storage (often RAID-10). Rotational SAS drives, even 15k RPM ones, effectively cap out at 150-200 IOPS per drive. A single heavy query from a neighbor on a shared HDD array can induce hundreds of milliseconds of I/O wait (%wa) for you.

Local Sovereignty: The Norwegian Context

Latency isn't just about disk speed; it's about network physics. If your primary user base is in Oslo, Bergen, or Trondheim, hosting in Germany or the US is a disservice to your users. A packet from Oslo to a US East Coast datacenter takes ~90-100ms round trip. Oslo to a local datacenter connected to NIX (Norwegian Internet Exchange)? Less than 2ms.

Furthermore, we must consider the Personopplysningsloven (Personal Data Act). While the Safe Harbor framework currently allows data transfer to the US, keeping data within Norwegian borders simplifies compliance with Datatilsynet regulations significantly. When you control the full KVM stack locally, you know exactly where your bits are rotting.

Optimizing Your KVM Instance for Production

Once you migrate to a KVM environment, you need to tune the kernel, as default Linux distributions are often tuned for desktop responsiveness, not server throughput. Here is a baseline sysctl.conf configuration for a web server handling high concurrent connections:

# /etc/sysctl.conf

# Increase system file descriptor limit
fs.file-max = 100000

# Improve TCP handling for high traffic
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1

# Increase the size of the receive queue
net.core.netdev_max_backlog = 2000

# Swappiness: Don't swap unless absolutely necessary (0 is valid in 2.6.32 kernels)
vm.swappiness = 0

Apply these changes with sysctl -p.

The Hardware Reality

Virtualization adds overhead; that is physics. But KVM combined with VirtIO drivers minimizes this gap. VirtIO allows the guest OS to know it is virtualized and cooperate with the hypervisor for network and disk operations, bypassing full emulation.

When provisioning your server on CoolVDS, ensure you are using the VirtIO drivers for both disk and network interfaces. You can verify this inside the VM:

lsmod | grep virtio
virtio_net             12345  0
virtio_blk             12345  2
virtio_pci             12345  0

If you don't see these, you are running in legacy emulation mode (IDE/Realtek), which is significantly slower.

Conclusion

In 2012, "cloud" is the buzzword, but isolation is the reality we need. OpenVZ is fine for a personal VPN or a low-traffic blog. But if your business depends on uptime, consistent latency, and data integrity, shared kernels are a liability you cannot afford.

We built CoolVDS on KVM because we got tired of debugging other people's resource usage. Whether you need low latency connectivity to NIX or the raw I/O throughput of Enterprise SSD storage, the foundation must be solid.

Ready to stop sharing your CPU? Deploy a KVM instance with root access in Oslo today.