OpenVZ Containers: The Good, The Bad, and The Oversold

Let’s be honest. If you have been in the hosting game since the late 2000s, you have been burned by a "budget" VPS provider. You buy a slice with 512MB RAM, you set up a basic LAMP stack, and suddenly MySQL crashes every six hours. You check the logs. Nothing. You check dmesg. Nothing.

Welcome to the world of OpenVZ overselling. While container-based virtualization is efficient, it is also the favorite weapon of hosting companies who want to cram 100 customers onto a single server that should only hold 20. At CoolVDS, we believe in transparency. If you are deploying critical infrastructure in Norway—whether it's a Magento store or a backend for a mobile app—you need to understand what is actually happening under the hood of your virtual machine.

The Architecture: Shared Kernel vs. Hardware Virtualization

OpenVZ (Open Virtuozzo) is operating-system-level virtualization. It uses a single Linux kernel (usually a RHEL6 based 2.6.32 kernel these days) patched to support containers. This means every VPS on the host node talks directly to the same kernel.

The Pro: It is incredibly lightweight. There is almost no emulation overhead. Disk I/O is native. Scaling resources is instant via vzctl commands.

The Con: Isolation is thin. If a neighbor on your node finds a kernel exploit or triggers a kernel panic, your server goes down too. Furthermore, you cannot load your own kernel modules. Need a specific VPN module or a custom TCP congestion control algorithm? You are out of luck unless the host enables it.

The "Burst RAM" Trap: Analyzing User Beancounters

The biggest pain point in 2012 isn't CPU; it's memory management. In KVM or Xen (HVM), RAM is allocated like physical hardware. In OpenVZ, it's managed via User Beancounters (UBC). This is where the "failcnt" (fail count) nightmare begins.

Many providers advertise "Burst RAM." They give you 256MB guaranteed and 512MB burst. But that burst memory is only available if the host node has free RAM. If the node is busy, and your Apache process tries to grab that burst memory, the kernel kills it instantly. No swap. Just death.

Here is how you check if your provider is strangling your resources. Run this on your OpenVZ instance:

cat /proc/user_beancounters

You will see output like this. Pay close attention to the last column:

Version: 2.5
       uid  resource           held    maxheld    barrier      limit    failcnt
      101:  kmemsize        2646000    2942000   11055923   11379916          0
            lockedpages           0          0        256        256          0
            privvmpages       64210      98200      65536      69632      14021
            physpages         12100      18500          0 2147483647          0
            vmguarpages           0          0      33792 2147483647          0
            oomguarpages      12100      18500      26112 2147483647          0
            ...

See that 14021 under failcnt for privvmpages? That means your applications requested memory 14,021 times and were told "No." This is why your Java application or MySQL InnoDB pool keeps crashing.

When to Use OpenVZ (and When to Run Away)

OpenVZ isn't useless. It is fantastic for specific scenarios where raw throughput matters more than strict isolation.

Use OpenVZ if:

• You are running a DNS cluster (Bind/PowerDNS) where memory usage is predictable.
• You need to spin up 50 dev environments in seconds.
• You are running a VPN tunnel (OpenVPN) and the host has enabled TUN/TAP.

Use KVM (CoolVDS Performance Tier) if:

• You need strict resource guarantees (RAM is RAM).
• You are running a database (MySQL/PostgreSQL) with high concurrency.
• You need to modify kernel parameters in sysctl.conf like net.ipv4.tcp_tw_reuse.
• Privacy is paramount (complying with the Norwegian Personal Data Act / Personopplysningsloven).

Optimizing MySQL 5.5 on a Constrained OpenVZ VPS

If you are stuck on a legacy OpenVZ slice, you cannot just use the default my.cnf. The defaults will eat your RAM and trigger the UBC limits. You must manually calculate your InnoDB buffer pool.

For a 512MB VPS, configure /etc/my.cnf carefully:

[mysqld]
# Do not use default settings on a 512MB VPS
skip-external-locking
key_buffer_size = 16M
max_allowed_packet = 1M
table_open_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M

# The most important setting for InnoDB
# Set this to 50-60% of AVAILABLE RAM, not total RAM
innodb_buffer_pool_size = 128M
innodb_log_file_size = 32M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 2 # Faster, slightly less ACID compliant

Note the innodb_flush_log_at_trx_commit = 2. On OpenVZ nodes with slow mechanical SAS drives, this prevents I/O blocking during transactions. If the node crashes, you might lose 1 second of data, but your site won't hang.

The Storage Bottleneck: Why SSD Changes Everything

In 2012, most VPS providers are still spinning 15k RPM SAS drives in RAID 10. They are reliable, but when 40 containers all decide to write logs at the same time, I/O wait spikes. We have seen load averages hit 100+ on host nodes simply due to disk contention.

Pro Tip: Check your disk latency with ioping (if available) or a simple dd test. If your write speed is under 40MB/s, you are on an overloaded node.

This is why CoolVDS has rolled out Pure SSD storage tiers. Solid State Drives eliminate the seek time latency that kills virtualized performance. While SSD space is more expensive per GB than spinning rust, the IOPS (Input/Output Operations Per Second) are 50x higher. For a database server, 10GB of SSD storage is worth 500GB of SATA storage.

Data Privacy and "The Neighbor Effect"

Operating in Norway, we have to respect the Datatilsynet regulations. With OpenVZ, you are technically sharing kernel memory space. While privilege escalation exploits are rare, they exist. For clients handling sensitive data under the 1995 EU Data Protection Directive, we almost always recommend KVM (Kernel-based Virtual Machine).

KVM provides full hardware virtualization. Your memory is yours. Your kernel is yours. If a neighbor gets DDoS'd, your network stack remains separate (mostly). It costs more CPU overhead to virtualize the hardware, but modern processors with VT-x instructions handle this beautifully.

Conclusion: Choose the Right Tool

Stop letting "Burst RAM" marketing fool you. If your project is mission-critical, you need dedicated resources. OpenVZ is fine for a personal proxy or a testing sandbox, but the unpredictability of User Beancounters is a liability for business.

At CoolVDS, we offer both, but we are seeing a massive shift toward our SSD-powered KVM nodes. The combination of hardware isolation and the lightning-fast random I/O of solid-state storage makes it the only logical choice for high-performance hosting in Europe.

Need consistent I/O for your database? Deploy a CoolVDS SSD KVM instance today and stop fighting for resources.