Re: SSD performance

I don't think write caching on the disks is a risk to data integrity if you are configured correctly.
Furthermore, these drives don't use the RAM for write cache, they only use a bit of SRAM on the controller chip for that (and respect fsync), so write caching should be fine.

Confirm that NCQ is on (a quick check in dmesg), I have seen degraded performance when the wrong SATA driver is in use on some linux configs, but your results indicate its probably fine.

How much RAM is in that machine?

Some suggested tests if you are looking for more things to try :D
-- What affect does the following tuning have:

Turn the I/O scheduler to 'noop' ( echo noop > /sys/block/<devices>/queue/scheduler) I'm assuming the current was cfq, deadline may also be interesting, anticipatory would have comically horrible results.
Tune upward the readahead value ( blockdev -setra <value> /dev/<device>) -- try 16384 (8MB) This probably won't help that much for a pgbench tune, its more for large sequential scans in other workload types, and more important for rotating media.
Generally speaking with SSD's, tuning the above values does less than with hard drives.

File system effects would also be interesting. If you're in need of more tests to try, compare XFS to EXT3 (I am assuming the below is ext3).

On 2/3/09 9:54 AM, "Jeff" <threshar(at)torgo(dot)978(dot)org> wrote:

I somehow managed to convince the powers that be to let me get a
couple X25-E's.
I tossed them in my macpro (8 cores), fired up Ubuntu 8.10 and did
some testing.

Raw numbers are very impressive. I was able to get 3700 random seek
+read's a second. In a R1 config it stayed at 3700, but if I added
another process it went up to 7000, and eventually settled into the
4000s. If I added in some random writing with fsyncs to it, it
settled at 2200 (to be specific, I had 3 instances going - 2 read-only
and 1 read-20% write to get that). These numbers were obtained
running a slightly modified version of pgiosim (which is on
pgfoundtry) - it randomly seeks to a "block" in a file and reads 8kB
of data, optionally writing the block back out.

Now, moving into reality I compiled 8.3.latest and gave it a whirl.
Running against a software R1 of the 2 x25-e's I got the following
pgbench results:
(note config tweaks: work_mem=>4mb, shared_buffers=>1gb, should
probably have tweaked checkpoint_segs, as it was emitting lots of
notices about that, but I didn't).

(multiple runs, avg tps)

Scalefactor 50, 10 clients: 1700tps

At that point I realized write caching on the drives was ON. So I
turned it off at this point:

Scalefactor 50, 10 clients: 900tps

At scalefactor 50 the dataset fits well within memory, so I scaled it
up.

Scalefactor 1500: 10 clients: 420tps

While some of us have arrays that can smash those numbers, that is
crazy impressive for a plain old mirror pair. I also did not do much
tweaking of PG itself.

While I'm in the testing mood, are there some other tests folks would
like me to try out?

--
Jeff Trout <jeff(at)jefftrout(dot)com>
http://www.stuarthamm.net/
http://www.dellsmartexitin.com/