neslonek.homeunix.org

For some time I am benchmarking PostgreSQL on DragonFly (www.dragonflybsd.org) and the HAMMER filesystem. In the week before the final release of DragonFly 2.6 we were able to discover a rather little bug in the HAMMER code that was causing random I/O performance to drop significantly. It turned out to be a counter in cluster_read that wasn't reduced correctly on random I/O, leading to intensive read-aheads even for pure random I/O loads.

I did some basic tests on my KVM host "monster" with dd to figure out the disk I/O performance of the host in comparison to it's guests. For this I ran dd if=/dev/zero bs=1M count=16384 directly onto a raw 50GB device (LVM2 LV on raid-5 array, see previous post for bonnie benchmarks of that). The results are quite astonishing:

Linux-2.6.32-trunk-amd64 (native): 140 MB/s
DragonFly-2.5.1.803.g905ff (virtualized): 131,7 MB/s

Where the host has 8GB of RAM and the VM only 1GB of RAM.

A few days ago I bought three Seagate Barracuda 7200.11 1,5TB. Unfortunatley one of them was DOA - well, dead after 3h of syncing the array. Finally I got the replacement and the array is up and running. Here are the bonnie benchmarks run a 50G LVM2 LV with ext4 fs on debian testing:

Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP


Luckily I was able to sell more of my old Alpha Hardware in the last few days. Today FedEx came by to pick up three boxes with DEC Alphaservers 300 and some external disks which go to the US. The money I got for them was directly invested into some SSDs for use with DragonFly BSD's (http://www.dragonflybsd.org) amazing new swapcache feature.