The "Unlimited Storage" Lie
Open any hosting brochure in 2010 and you will see the same promises: "Unlimited Bandwidth," "Unlimited Storage," "Cloud Scalability." It sounds fantastic until you actually try to run a write-heavy InnoDB database on a standard cloud instance. Suddenly, your site creates a massive backlog, your load average spikes to 20.0, and your users in Oslo are staring at a white screen. Why? Because while they sold you gigabytes, they didn't mention IOPS (Input/Output Operations Per Second).
As systems architects, we need to stop looking at capacity and start obsessing over latency. In a shared storage environment (common in "Cloud" setups using heavy SANs), your disk writes are traversing a network cable, competing with every other noisy neighbor in the datacenter. For static assets, S3 is fine. For a transactional database? It is suicide.
Diagnosing the Silent Killer: iowait
I recently audited a Magento installation for a client in Trondheim. They had plenty of RAM, but the site crawled. A simple check revealed the truth:
root@server:~# iostat -x 1
avg-cpu: %user %nice %system %iowait %steal %idle
1.50 0.00 2.10 45.80 0.00 50.60That 45.80% iowait means the CPU is sitting idle, twiddling its thumbs, waiting for the disk to confirm data is written. The storage subsystem simply cannot keep up. In a virtualized environment, this is often caused by the hypervisor scheduling I/O poorly or a saturated RAID controller on the host node.
The Architecture of Speed: Local RAID vs. SAN
To fix this, you have two choices. You can spend a fortune on a Fibre Channel SAN, or you can opt for local storage with strict isolation. This is where the choice of virtualization technology becomes critical.
At CoolVDS, we deliberately chose Xen HVM over container-based virtualization like OpenVZ for our high-performance tiers. Why? Because OpenVZ shares the kernel and often the I/O scheduler more aggressively. Xen allows us to allocate dedicated disk slices backed by hardware RAID-10 arrays. This isolation ensures that when your neighbor compiles a kernel, your database doesn't stall.
Pro Tip: Filesystem Tuning
If you are running on a Linux VPS, ensure you aren't updating file access times on every read. Open your/etc/fstaband add thenoatimeflag to your root partition:/dev/xvda1 / ext3 defaults,noatime,errors=remount-ro 0 1
This simple change can reduce disk writes by 20-30% on read-heavy web servers.
The Emerging SSD Revolution
We are currently seeing the very early adoption of Solid State Drives (SSDs) in the enterprise. While standard spinning rust (even 15k RPM SAS drives) tops out around 180-200 IOPS, enterprise SSDs like the Intel X25-E can push thousands. While still cost-prohibitive for mass storage, using SSDs for your MySQL data directory (/var/lib/mysql) is the single biggest upgrade you can make in 2010.
We are currently testing SSD-backed caching on our storage nodes at CoolVDS to bridge this gap, bringing the latency down from milliseconds to microseconds.
Data Sovereignty: The Norwegian Advantage
Performance isn't just about disk speed; it's about network topology. If your customers are in Norway, hosting in a datacenter in Texas or even Frankfurt introduces unavoidable latency. Light can only travel so fast.
Furthermore, we must navigate the Norwegian Personal Data Act (Personopplysningsloven). With the uncertainty surrounding US-EU data transfers (Safe Harbor is a legal minefield), keeping your data physically located in Norway is the only way to ensure 100% compliance with Datatilsynet requirements. Hosting locally gives you low latency and legal peace of mind.
Configuration: Optimizing MySQL for Virtualized Storage
If you cannot migrate to SSDs yet, you must tune InnoDB to be less aggressive with disk syncing. While this introduces a slight risk in the event of a total power failure, it can save a server drowning in I/O.
[mysqld]
# Default is 1 (safest). Set to 2 to flush to OS cache, not physical disk, per transaction.
innodb_flush_log_at_trx_commit = 2
# Increase buffer pool to hold more data in RAM (70% of total RAM is a good rule of thumb)
innodb_buffer_pool_size = 2GConclusion
Don't be fooled by "unlimited cloud" marketing. If your application relies on database transactions, you need guaranteed I/O, not just capacity. By utilizing Xen virtualization, local RAID-10 SAS (or emerging SSDs), and hosting directly on the NIX (Norwegian Internet Exchange) backbone, you eliminate the bottlenecks that kill conversion rates.
Ready to stop waiting on your hard drive? Deploy a high-performance Xen instance on CoolVDS today and see what single-digit millisecond latency feels like.