OpenVZ vs. KVM: The Truth About "Burst RAM" and Overselling in 2011
It is 3:00 AM. Your monitoring system—maybe Nagios, maybe a custom script—is screaming. Your MySQL slave has crashed. Again. You log in, check top, and everything looks fine. Plenty of free memory. Low load average. So why did the OOM (Out of Memory) killer sacrifice your database?
If you are hosting on a budget VPS, the answer is likely hiding in a file most developers never check: /proc/user_beancounters.
In the rush to grab the cheapest hosting deals, many SysAdmins overlook the underlying virtualization technology. In 2011, the market is flooded with dirt-cheap OpenVZ offers. While OpenVZ is a brilliant piece of engineering for density, it is often abused by providers to pack hundreds of customers onto a single physical node. Today, we are stripping away the marketing fluff to look at the kernel-level reality of Containers vs. Hardware Virtualization.
The Architecture: Shared Kernel vs. Dedicated Hardware
To understand the performance issues, you have to understand the stack. OpenVZ is operating-system-level virtualization. There is one Linux kernel running on the host node. Every VPS (container) on that node talks directly to that single kernel.
The Pro: It is incredibly efficient. There is no emulation overhead. Disk I/O is nearly native. You can resize a container from 512MB RAM to 4GB RAM instantly with a vzctl set command without a reboot.
The Con: You are married to your neighbors. If another customer on the same physical server decides to run a heavy PHP script or gets hit by a DDoS attack, the shared kernel lock contention can degrade your performance. Furthermore, you cannot load your own kernel modules. Need a specific version of iptables or FUSE support? You are at the mercy of the host's configuration.
The "Burst RAM" Myth
This is where most people get burned. OpenVZ providers advertise "Burst RAM." They tell you: "You get 512MB Guaranteed and 1GB Burst!"
It sounds generous. It isn't. "Burst" memory is essentially available only if the node is underutilized. If the node fills up, and your application tries to access that burst memory, the kernel says no. Unlike swap space on a physical server or KVM slice, the fail state here isn't just slowing down—it's immediate process termination.
Pro Tip: Run this command on your VPS right now:
cat /proc/user_beancounters
Look at the last column, failcnt. If you see any number other than 0 next toprivvmpages, your provider is hitting limits, and your processes are being killed silently. Reliable hosting requires Guaranteed RAM, not marketing fluff.
When to Use OpenVZ (and When to Run Away)
OpenVZ isn't bad technology; it is just frequently misused. At CoolVDS, we deploy OpenVZ for specific use cases where raw efficiency beats isolation, but we do it differently. We enforce strict node density limits to prevent the "noisy neighbor" effect.
| Feature | OpenVZ Container | KVM / Xen HVM |
|---|---|---|
| Performance Overhead | Near Zero (Native) | Low (1-2% due to emulation) |
| Kernel Access | Shared (Host Kernel) | Dedicated (Your own Kernel) |
| Stability | Dependent on neighbors | Isolated |
| Best Use Case | DNS, VPN, Dev/Staging, lightweight Web | High-load DB, Java Apps, Production |
The Norwegian Context: Latency and Law
For those of us operating out of Norway, the physical location of the host node is just as critical as the virtualization type. Routing traffic through Frankfurt or London adds milliseconds that kill the "snappiness" of a site. By peering directly at NIX (Norwegian Internet Exchange) in Oslo, we ensure low latency for local users.
Furthermore, we have to consider the Personopplysningsloven (Personal Data Act). Storing customer data outside of the EEA or in unstable jurisdictions is a legal minefield. Using a Norwegian provider ensures you remain compliant with Datatilsynet's strict requirements regarding data sovereignty.
Configuration: Tuning for Stability
If you are stuck on an OpenVZ node, you need to optimize your stack to respect the strict memory limits. The default MySQL configuration in CentOS 5 or 6 is often too aggressive for a small container.
Edit your /etc/my.cnf to lower the memory footprint:
[mysqld]
skip-innodb
key_buffer_size = 16M
query_cache_size = 8M
thread_cache_size = 4
Note: If you are running a modern Magento store or a heavy Drupal site, disable MyISAM and use InnoDB, but be prepared to buy a larger slice or switch to KVM.
The CoolVDS Approach: Honest Resources
We believe that "unlimited" plans are a lie. CPU cycles and disk I/O are finite resources. Whether you choose our high-efficiency OpenVZ containers or our fully isolated KVM instances, we guarantee the resources you pay for.
We are also rolling out new nodes equipped with Enterprise SSDs in RAID-10. In 2011, rotating rust (HDDs) is still the standard, but for database-heavy applications, the IOPS provided by Solid State Drives are a game changer. We see boot times drop from minutes to seconds.
If your current host is showing high failcnt values or your latency to Oslo is lagging, it’s time to rethink your infrastructure.
Ready for stability? Deploy a test instance on CoolVDS today. We provision in under 60 seconds, and we never oversell.