The "Burst RAM" Lie: A SysAdmin's Guide to OpenVZ in 2011

If I see one more hosting provider advertising "Unlimited Burst RAM" for $5 a month, I might just unplug my rack and move to a cabin in Finnmark. In the fast-moving world of 2011 hosting, virtualization is the buzzword, but not all virtual private servers (VPS) are created equal. You have likely seen the offers: massive specs for pennies. But when you deploy your Magento store or vBulletin forum, the server crawls, and top shows load averages spiking for no reason.

The culprit? Usually, it is OpenVZ overselling.

At CoolVDS, we believe in transparency. Whether you are running a startup in Oslo or managing a legacy LAMP stack for a client in Bergen, understanding the architecture under the hood is critical. Today, we are tearing down OpenVZ containers: the good, the bad, and the ugly.

The Architecture: Shared Kernel vs. Hardware Virtualization

To understand why your database keeps crashing, you have to understand how OpenVZ works. Unlike Xen or the emerging KVM (Kernel-based Virtual Machine) technology, OpenVZ is operating system-level virtualization.

In an OpenVZ environment, every container (VE) shares the exact same Linux kernel as the host node. There is no hypervisor layer translating instructions; it is just a chrooted environment on steroids.

The Pros: Why Hosts Love It

• Efficiency: Since there is no kernel emulation overhead, the performance is nearly native—if the host isn't overloaded.
• Density: A host can pack hundreds of containers on a single physical server. This is how providers sell VPS slots for the price of a latte.
• Instant Scaling: You can change resources on the fly without a reboot. Need more RAM? A simple command on the host node applies it instantly.

The Cons: The "Noisy Neighbor" Effect

Here is the reality for the battle-hardened sysadmin: OpenVZ lacks strict isolation. If one user on the node gets hit by a DDoS attack or runs a poorly optimized PHP script that forks 500 processes, your performance suffers. The I/O wait shoots up, and your legitimate traffic to NIX (Norwegian Internet Exchange) slows to a crawl.

The Dreaded User Beancounters

If you have ever managed an OpenVZ box, you know this file: /proc/user_beancounters. This is where the magic (and misery) happens.

Unlike Xen, which allocates a hard block of RAM, OpenVZ uses a complex set of limits. The most deceptive is "Burst RAM." A host might promise you 512MB guaranteed and 1GB burst. But that burst memory is only available if the host node has free RAM. If the node is full (which it always is on budget hosts), your process gets killed immediately when it tries to burst.

Pro Tip: Run this command on your VPS to see if you are hitting limits: cat /proc/user_beancounters | grep failcnt If the last column (failcnt) is anything other than 0, your provider is throttling you. You might see privvmpages errors, which often look like "Cannot allocate memory" in your Apache error logs, even when free -m says you have plenty of RAM left.

Security and Kernel Modules

Because you share the kernel, you are at the mercy of the host's kernel version (usually a heavily patched RHEL or CentOS 5 kernel). You cannot load your own kernel modules.

• Need a specific iptables module for your firewall? If the host hasn't loaded it, you can't use it.
• Want to run a specialized VPN protocol? Often impossible strictly inside the container (TUN/TAP devices often need host activation).
• Privacy: While we adhere strictly to the Personal Data Act here in Norway, on a technical level, an OpenVZ root user is not as isolated as a Xen root user. A kernel panic triggered by one container can take down the entire node.

When Should You Use OpenVZ?

OpenVZ isn't useless. It is fantastic for:

1. Development/Staging: Spin it up fast, break it, rebuild it.
2. DNS Servers: Low resource usage, simple daemon requirements.
3. Personal Proxies/VPNs: Provided the TUN/TAP device is enabled.

However, for a high-traffic e-commerce site or a mission-critical database, you are gambling with uptime.

The CoolVDS Standard: Xen and KVM

We see the market shifting. While we support legacy OpenVZ for specific use cases, for serious production workloads, we push hardware virtualization (Xen HVM or KVM). This provides true isolation. If you have 2GB of RAM, that RAM is yours. No one can steal it. You can run your own kernel, compile your own modules, and define your own swap partition.

Storage Speed Matters: The Move to SSD

Another bottleneck in 2011 is the spinning rust. Traditional SATA drives in RAID arrays struggle when 50 containers all try to write logs simultaneously. That is why CoolVDS is rolling out Solid State Drive (SSD) storage options. While pricey compared to standard HDDs, the random I/O performance of SSDs eliminates the I/O wait that paralyzes OpenVZ nodes.

If you are serious about SEO, you know Google is starting to care about site speed. Don't let a slow disk subsystem ruin your rankings.

Final Verdict

Don't be fooled by the marketing fluff of "unlimited resources." In the datacenter, physics still applies. If you need low latency connectivity within Norway and guaranteed resources that won't vanish during peak hours, you need a provider that respects the hardware.

Ready to stop fighting failcnt errors? Deploy a true hardware-virtualized instance on CoolVDS today. We combine premium connectivity to the Norwegian Internet Exchange (NIX) with honest resource allocation. No tricks, just raw power.