OpenVZ Containers: The Good, The Bad, and The "Failcnt"

It starts the same way for every junior sysadmin. You find a provider on WebHostingTalk offering a 512MB RAM VPS for the price of a latte. You deploy your LAMP stack, and everything feels snappy. Then, Tuesday afternoon hits. Your SSH session lags. Apache starts dropping connections. You check top and see... nothing. Your load is low, but the server is crawling.

Welcome to the world of OpenVZ overselling. As we scale infrastructure across Norway, from small dev shops in Bergen to enterprise deployments in Oslo, we see this story on repeat. OpenVZ is a powerful tool, but in 2010, it is also the most misunderstood technology in the hosting market.

The Architecture: Shared Kernel vs. The World

To understand why your database is choking, you have to look under the hood. OpenVZ uses OS-level virtualization. Unlike Xen or the emerging KVM technology, which emulate hardware, OpenVZ containers share the host's Linux kernel. This means a container is essentially a glorified chroot environment with resource limits applied.

The Pro: Efficiency. There is almost zero overhead. A host node can run hundreds of containers because it's not emulating BIOS, PCI buses, or disk controllers for each one.

The Con: The "Noisy Neighbor." If another customer on the same physical node decides to compile a custom kernel (which they can't actually boot, but the compilation eats CPU) or run a poorly indexed MySQL query, the host kernel scheduler has to manage that load. If the host is oversold—which is common in budget hosting—your "guaranteed" CPU cycles vanish.

The Smoking Gun: /proc/user_beancounters

If you are on an OpenVZ system and experiencing mysterious crashes or "Out of Memory" errors despite having free RAM, run this command immediately:

cat /proc/user_beancounters

You will see a column called failcnt. This is the counter of shame. In OpenVZ, memory isn't just memory. It's split into complex parameters like privvmpages (allocated memory) and kmemsize (kernel memory).

Expert Tip: Many providers set the privvmpages limit high (so they can advertise "1GB RAM") but set kmemsize low. The result? Apache tries to fork a new process, hits the kernel memory limit, and crashes, even though you technically have free RAM. At CoolVDS, we don't play these games. Our resource allocation is transparent.

Security Implications in a Shared Environment

Security is paramount, especially with the Personopplysningsloven (Personal Data Act) enforcing strict standards for how we handle Norwegian user data. In an OpenVZ environment, a kernel panic is a mass extinction event. If the host kernel crashes, every single container on that node goes down instantly.

Furthermore, because you are sharing a kernel (often an older RHEL 5 / CentOS 5 kernel specifically patched for OpenVZ), you are reliant on the host to patch vulnerabilities. You cannot upgrade your kernel. If there is a local root exploit in that specific kernel version, isolation between containers can theoretically be breached.

Comparison: OpenVZ vs. Xen/KVM

When is OpenVZ the Right Choice?

I’m not saying OpenVZ is dead. It serves a purpose. If you need to spin up 50 lightweight DNS servers or a testing environment that will be destroyed in an hour, the provisioning speed is unbeatable. It takes seconds.

However, for a production Magento store or a critical database backend serving users in Oslo? It’s a gamble. The disk I/O scheduling in OpenVZ is often shared across the whole node. One user doing heavy I/O operations can choke the disk queue for everyone else, causing what we call "I/O Wait" spikes.

The CoolVDS Approach: Stability First

At CoolVDS, we have made a strategic decision to prioritize reliability over density. While we offer containerized solutions for specific use cases, our primary infrastructure is built on hardware virtualization technologies like KVM and Xen.

Why? Because when you pay for a server, you expect your resources to be yours. We utilize enterprise-grade RAID-10 SAS storage arrays to ensure that even if you choose a virtualized environment, your I/O throughput remains consistent. We peer directly at NIX (Norwegian Internet Exchange) to ensure that your latency to Norwegian customers is minimal—often under 2ms within Oslo.

Don't let a failcnt determine your uptime. If you are tired of mysterious crashes and variable performance, it's time to own your resources.

Ready for consistent performance? Deploy a true hardware-isolated VPS on CoolVDS today and see the difference real dedication makes.