On 11/15/05 8:35 AM, "Joost Kraaijeveld" <J.Kraaijeveld@xxxxxxxxxx> wrote:
thousand go relatively fast, after that PostgreSQL crawls to a halt
(other "benchmarks" like bonnie++ or just dd'ing a big file don't have
this behavior).
With RAID5, it could matter a lot what block size you run your “dd bigfile” test with. You should run “dd if=/dev/zero of=bigfile bs=8k count=500000” for a 2GB main memory machine, multiply the count by (<your mem>/2GB).
It is very important with the 3Ware cards to match the driver to the firmware revision.
I did notice that changing the I/O scheduler's nr_request from theYou could try deadline, there’s no harm, but I’ve found that when you reach the point of experimenting with schedulers, you are probably not addressing the real problem.
default 128 to 1024 or even 4096 made a remarkable performance
improvement. I suspect that experimenting with other I/O schedululers
could improve performance. But it is hard to find any useful
documentation about I/O schedulers.
On a 3Ware 9500 with HW RAID5 and 4 or more disks I think you should get 100MB/s write rate, which is double what Postgres can use. We find that Postgres, even with fsync=false, will only run at a net COPY speed of about 8-12 MB/s, where 12 is the Bizgres number. 8.1 might do 10. But to get the 10 or 12, the WAL writing and other writing is about 4-5X more than the net write speed, or the speed at which the input file is parsed and read into the database.
So, if you can get your “dd bigfile” test to write data at 50MB/s+ with a blocksize of 8KB, you should be doing well enough.
Incidentally, we also find that using the XFS filesystem and setting the readahead to 8MB or more is extremely beneficial for performance with the 3Ware cards (and with others, but especially for the older 3Ware cards).
Regards,
- Luke
