Shared memory between workers
gleb.lists at pluron.com
Wed Apr 28 20:12:40 EDT 2010
> 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.
More information about the mongrel-unicorn