6 Answers
6

The major limiting factor for synchronous IO isn't throughput of your harddrive, but rather the time it takes from when the write is issued and it being committed to disk. The most relevant performance metric for a harddrive in this regard would be the seek time of the harddrive and not it's throughput under ideal circumstances.

In addition to the hardware working against you, so are the kernel, I'm guessing you might see a small improvement (although, probably nowhere near what you'll get from doing async IO) if you can ionice the benchmark (application) to run under the realtime IO scheduling class. By default, applications will be scheduled under the best effort class, which probably also will add to the wait time of your writes. Use the realtime scheduling class at your own risk, as it'll have adverse effects on other applications performance when accessing disk.

A synchronous write must receive back an acknowlegement that the write has been committed (wether the commit was a success or error) before it can return itself. This is by design, and inherently makes synchronous writes much slower due to the high latency times involved with a spinning metal disk (on disk ram cache doesn't count).

Asynchronous writes are usually written to RAM and the OS deals with committing it to disk later (later usually being mere seconds or less (I believe ZFS is 5x/second, or every 5 seconds)). Disk seek times are measured in ms while RAM seek times are measured in ns. That's a difference of 1000x.

Use synchronous writes when it's absolutely critical that the data is permanently stored before continuing and a 1 second delay where power loss may occur is unacceptable.

The cfq I/O scheduler tends to perform horribly in these sorts of tests. In addition to the ionice suggestion earlier, you might want to try switching to the deadline I/O scheduler (either by booting with elevator=deadline or by doing for n in /sys/block/sd*/queue/scheduler ; do echo deadline > $n ; done as root).

Synchronous writes are slow, its why we buffer everything. Take a look at IOPS on Wikipedia and you will see a typical 7,200 rpm HDD has 75-100 IOPS. Now take a look at the technical specs of a Macbook Pro, and it has a 5,400 rpm HDD. That's 75% performance at best so you are looking at 50-75 IOPS at best for the laptop.

A MQ maybe writing a data ledger and an accounting ledger, which gets you to the 20 IOPS you are seeing in the ActiveMQ benchmark.

You have two options, test on tmpfs, i.e. in-memory file system, or use a SSD. Normally servers using synchronous writes will have a significant SAS/SCSI RAID array with 15,000 rpm disks. Extra disks are added to the array to improve performance, not to increase capacity.

I wonder if the OP was running this in a VM as well or if there is a problem between ext3 and ext4. I appreciate that there could be a difference between hosted and non-hosted environments, however did not expect such a great difference.