The "Burst RAM" Trap: Why Shared Kernels Kill Performance

It is 3:00 AM. Your monitoring system—Nagios, if you're sensible—is screaming. Your client's Magento store is down. You SSH in, but the terminal lags by three seconds per keystroke. You check top and see... nothing. Your load average is 0.2. Your CPU is idle. Yet, the server is unresponsive.

Welcome to the hell of oversold OpenVZ hosting. While every budget provider in Europe is pushing these container-based Virtual Private Servers (VPS) as the "next big thing" for cost efficiency, they often conveniently forget to mention the architectural trade-offs. As a systems architect managing infrastructure across the Nordics, I have seen too many projects fail because they treated a container like a dedicated server. They are not the same.

The Architecture: Containers vs. Hypervisors

To understand why your database keeps crashing, you need to understand the underlying kernel mechanics. OpenVZ is operating system-level virtualization. It uses a single, shared Linux kernel (usually a patched Red Hat Enterprise Linux 6 kernel these days) across all tenants on the physical node.

The Pros: It is lightweight. You can cram hundreds of containers onto one physical server because there is no emulation overhead.

The Cons: You are at the mercy of your neighbors. If another customer on the same physical node decides to compile a custom kernel or gets hit by a DDoS attack, your I/O wait shoots through the roof. Worse, you cannot load your own kernel modules. Need a specific version of ip_conntrack for your firewall rules? Too bad.

The "User Beancounters" Nightmare

In a KVM (Kernel-based Virtual Machine) environment—which is what we strictly use for our premium tiers at CoolVDS—RAM is RAM. In OpenVZ, RAM is a lie called "Burst Memory."

OpenVZ resources are controlled by a mechanism called user_beancounters. It limits not just memory, but the number of files you can open, the number of sockets, and even the size of TCP buffers.

Here is a command you should run right now if you are on an OpenVZ slice:

You will see output looking like this:

Version: 2.5
       uid  resource           held    maxheld    barrier      limit    failcnt
      101:  kmemsize        2607869    2894302   14336000   14790160          0
            lockedpages           0          0        256        256          0
            privvmpages       68912      89415     262144     302144        412
            shmpages            671        671      21504      21504          0
            dummy                 0          0          0          0          0
            numproc              29         32        240        240          0
            physpages         29411      35121          0 2147483647          0
            vmguarpages           0          0      33792 2147483647          0
            oomguarpages      29411      35147      26112 2147483647          0

See that failcnt column? That stands for "fail count." If that number is anything other than zero, your application has been silently denied resources by the host node. In the example above, privvmpages has a fail count of 412. This means 412 times, a process tried to allocate memory and the kernel said "no," likely killing your MySQL process instantly.

War Story: The "Ghost" Outage

Last month, we migrated a client from a budget German host to our Oslo facility. They were running a standard LAMP stack (Linux, Apache 2.2, MySQL 5.5, PHP 5.3). Every day at 14:00, their site threw 500 Internal Server Errors.

Their previous host support claimed everything was fine. "Your VPS is online," they said.

We dug into the logs. It wasn't their traffic. It was a neighbor on the same physical node running a massive backup script that saturated the SATA disk array (I/O saturation). Because OpenVZ shares the I/O scheduler, the client's MySQL queries timed out waiting for the disk to spin.

Pro Tip: If you must use OpenVZ, optimize your MySQL configuration to be extremely conservative with memory buffers, as you don't have a real swap partition.

Here is a safer my.cnf configuration for a 512MB VPS to prevent the OOM (Out of Memory) killer:

[mysqld]
# Reduce buffer pool size to leave room for Apache
innodb_buffer_pool_size = 64M

# Disable query cache to save RAM overhead
query_cache_size = 0
query_cache_type = 0

# Lower connection limits
max_connections = 50

# Per-thread buffers - keep these small!
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K

Why KVM (and CoolVDS) is the Superior Choice

This is why CoolVDS champions KVM virtualization. With KVM, the Linux kernel acts as a hypervisor. Your OS is fully isolated. You have your own kernel, your own genuine swap partition, and most importantly, strict resource isolation.

When you buy a KVM VPS from us, you get:

• True Hardware Virtualization: Run CentOS, Debian, Ubuntu, or even FreeBSD.
• Dedicated Resources: No "burst" limits. If you buy 4GB RAM, you get 4GB RAM.
• Custom Kernels: Need to enable SELinux or specific `iptables` modules for security compliance? Go ahead.

The Norwegian Latency Advantage

Beyond virtualization types, physical location is the other bottleneck. If your customer base is in Norway, hosting in a datacenter in Texas or even Frankfurt adds latency.

Our infrastructure connects directly to the NIX (Norwegian Internet Exchange) in Oslo. We are talking about 2-5ms latency for local users versus 30-50ms from central Europe. In an era where Google is starting to prioritize page speed in search rankings, those milliseconds matter.

Data Privacy in 2012

We must also address the legal landscape. Under the Personopplysningsloven (Personal Data Act) and the guidelines from Datatilsynet, you are responsible for where your user data lives. Hosting outside the EEA requires strict adherence to the Safe Harbor principles. By keeping your data on servers physically located in Norway, you simplify compliance and ensure legal protection under Norwegian law.

Conclusion: Stop Sharing Your Kernel

OpenVZ has its place—mostly for testing or extremely low-budget personal blogs. But for business-critical applications, the risk of noisy neighbors and resource denial is too high. You need predictability.

We have just deployed new racks with enterprise-grade SSD storage (RAID-10) which obliterates the I/O bottlenecks common in older hosting environments. Don't let slow I/O or stolen CPU cycles kill your SEO.

Ready to upgrade? Deploy a true KVM instance on CoolVDS today and experience the stability of dedicated resources.