OpenVZ vs. Xen: The Dirty Truth About 'Burst RAM' and Overselling
It starts with a simple ticket. Your MySQL 5.1 service crashed again last night. No traffic spike, no error logs in /var/log/messages, just a dead database. You restart it, everything looks fine, and you move on. Until tomorrow.
If you are hosting on a budget VPS, you aren't fighting a software bug. You are likely fighting your neighbors. Welcome to the world of Operating System-level virtualization, specifically OpenVZ, and the dangerous allure of "Burst RAM."
At CoolVDS, we have seen too many sysadmins migrate to us after losing data to oversold nodes. In this post, we are going to dissect the OpenVZ architecture, look at why it dominates the low-end market, and why serious applications in 2010 need true hardware isolation like Xen.
The Architecture: Shared Kernel vs. Hypervisor
To understand the performance gap, you have to look at the kernel.
OpenVZ is container-based virtualization. There is one Linux kernel running on the host node. Every VPS (or "container") on that node shares that exact same kernel. The host uses a barrier to pretend you have your own OS, but you don't. You are effectively a fancy chroot with resource limits.
Xen (which we use for our premium tiers) uses a Hypervisor. It sits between the hardware and the OS. When you provision a Xen VPS, you are running a full, independent kernel. If a neighbor triggers a kernel panic, your server keeps humming along.
The "Burst RAM" Trap
This is where the marketing spin happens. OpenVZ providers often sell you a plan with "256MB Guaranteed RAM" and "512MB Burst RAM."
Burst RAM is a loan. It is memory the host allows you to use only if nobody else is using it. When the host node gets busy—say, during prime time traffic in Oslo—that Burst RAM vanishes instantly. If your MySQL InnoDB buffer pool was using that burst memory, the system kills the process immediately to save the node. No warning. No graceful shutdown.
Pro Tip: check your fail count
If you are on an OpenVZ system, run this command right now:cat /proc/user_beancountersLook for thefailcntcolumn. If you see any number other than 0 next toprivvmpages, your provider is starving your resources.
The Pros and Cons
We aren't saying OpenVZ is useless. It has its place. But you need to know the trade-offs before deploying production code.
| Feature | OpenVZ | Xen (Hardware Virtualization) |
|---|---|---|
| Performance | Near native (if not oversold) | Consistent, guaranteed resources |
| Kernel Modules | Impossible (can't load iptables modules manually) | Full control (tun/tap, customized kernels) |
| Swap | Fake (often counts against RAM limits) | Real, dedicated swap partition |
| Price | Cheap | Higher (cannot be oversold easily) |
The "Noisy Neighbor" Effect
In Norway, power stability is generally excellent, but network I/O is a finite resource. On OpenVZ, disk I/O scheduling is shared. If one user on your node decides to compile a massive software package or run a heavy backup script, the disk queue spikes for everyone.
We recently diagnosed a latency issue for a client in Stavanger. Their web server response time (TTFB) fluctuated between 200ms and 3000ms. The server configuration was perfect. The culprit? A neighbor on their budget OpenVZ host was hammering the RAID array.
Moving them to a dedicated Xen instance on CoolVDS stabilized the I/O immediately. Why? Because with Xen, we can set strict I/O priorities and dedicate CPU cores.
Data Privacy and Isolation (Datatilsynet)
Legal compliance is becoming stricter. Under the Norwegian Personal Data Act (Personopplysningsloven), you are responsible for securing sensitive user data. While OpenVZ has improved security, shared kernel exploits are a real vector. If a hacker manages a privilege escalation on the host kernel, they theoretically have access to every container on that node.
For simple static sites or development sandboxes, OpenVZ is cost-effective. But for anything handling customer data, credit cards, or critical infrastructure, the isolation gap is a risk you shouldn't take.
Optimizing for the Platform
If you are stuck on OpenVZ, you must configure your services conservatively. Do not trust the "Burst" limit.
For MySQL (my.cnf):
[mysqld]
# Don't set this higher than your GUARANTEED RAM minus system overhead
innodb_buffer_pool_size = 128M
skip-external-locking
key_buffer_size = 16M
If you are on CoolVDS Xen instances, you can push these limits much harder because the RAM is physically allocated to your virtual machine. It's yours. We don't lend it out.
Conclusion: You Get What You Pay For
Server administration is about risk management. OpenVZ offers high density and low price, making it great for students and testing. But the "Burst RAM" model is a gamble with your uptime.
If your business relies on consistent database performance and strict isolation, stop fighting /proc/user_beancounters. Upgrade to a virtualization technology that respects your resources.
Ready for real stability? Deploy a Xen-based VPS with CoolVDS today. We utilize high-performance RAID-10 SAS storage and connect directly to NIX (Norwegian Internet Exchange) for superior low-latency connectivity across Scandinavia.