| From: | Greg Smith <greg(at)2ndquadrant(dot)com> | 
|---|---|
| To: | Richard Neill <rn214(at)cam(dot)ac(dot)uk> | 
| Cc: | PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> | 
| Subject: | Re: SSD + RAID | 
| Date: | 2009-11-21 00:27:36 | 
| Message-ID: | 4B0733F8.10505@2ndquadrant.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
Richard Neill wrote:
> The key issue for short,fast transactions seems to be
> how fast an fdatasync() call can run, forcing the commit to disk, and
> allowing the transaction to return to userspace.
> Attached is a short C program which may be of use.
Right.  I call this the "commit rate" of the storage, and on traditional 
spinning disks it's slightly below the rotation speed of the media (i.e. 
7200RPM = 120 commits/second).    If you've got a battery-backed cache 
in front of standard disks, you can easily clear 10K commits/second.
I normally test that out with sysbench, because I use that for some 
other tests anyway:
sysbench --test=fileio --file-fsync-freq=1 --file-num=1 
--file-total-size=16384 --file-test-mode=rndwr run | grep "Requests/sec"
-- 
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com  www.2ndQuadrant.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2009-11-21 14:25:03 | Re: SSD + RAID | 
| Previous Message | Greg Smith | 2009-11-21 00:18:09 | Re: Postgres query completion status? |