> If you use a "on memory database" there wouldn't be filesystem locking, right?
fsync throughput (a.k.a. commit rate) is easy to test: sudo aptitude install sysbench sysbench --test=fileio --file-fsync-freq=1 --file-num=1 \ --file-total-size=16384 --file-test-mode=rndwr run \ | grep "Requests/sec" You can then see if any additional tuning (RAM drive, etc.) is even necessary for your requirements. Unless something is doing write-back caching in between the app and the drive this rate will be a function of RPM of your drive, e.g. ~120/s for 7200RPM We did a bunch of benchmarking when setting up a couple of DB servers recently and found that consumer-grade drives (SATA) lie and have write-back caching enabled by default, and you get 1-3k/s. It's not considered safe to run a database on such configuration as HDD cache lacks battery backup. For comparison we get ~10k/s on a 4 disk RAID 10 SAS array (w/ battery backup unit) with write-back caching turned on in the controller and off in the drives. So, the point is that consumer hardware lies and you are quite likely to get good fsync performance. Since you don't care about data safety for your setup this should be fine. Best regards, Gleb _______________________________________________ Unicorn mailing list - mongrel-unicorn@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
