Re: [PERFORM] Performance PG 8.0 on dual opteron / 4GB / 3ware</TITL= E> </HEAD> <BODY> Joost= , On 11/15/05 8:35 AM, "Joost Kraaijeveld" <J.Kraaijeveld@Askesi= s.nl> wrote: <BLOCKQUOTE>thousand go relatively fast, after that PostgreSQL craw= ls to a halt (other "benchmarks" like bonnie++ or just dd'ing a big file don't= have this behavior). </BLOCKQUOTE> With RAID5, it could matter a lot what block size you run your “dd bi= gfile” test with. You should run “dd if=3D/dev/zero of=3Dbigfi= le bs=3D8k count=3D500000” for a 2GB main memory machine, multiply the cou= nt by (<your mem>/2GB). It is very important with the 3Ware cards to match the driver to the firmwa= re revision. <BLOCKQUOTE>I did notice that changing the I/O scheduler's nr_reque= st from the 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. </BLOCKQUOTE>You could try deadline, there’s no harm, but I&#= 8217;ve found that when you reach the point of experimenting with schedulers= , you are probably not addressing the real problem. <BLOCKQUOTE> </BLOCKQUOTE>On a 3Ware 9500 with HW RAID5 and 4 or more disks I th= ink you should get 100MB/s write rate, which is double what Postgres can use= . We find that Postgres, even with fsync=3Dfalse, 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 w= riting is about 4-5X more than the net write speed, or the speed at w= hich 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 re= adahead to 8MB or more is extremely beneficial for performance with the 3War= e cards (and with others, but especially for the older 3Ware cards). Regards, - Luke </BODY> </HTML> --B_3214896142

X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id DE2BBDB831 for ; Tue, 15 Nov 2005 14:42:56 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 74148-02 for ; Tue, 15 Nov 2005 18:42:55 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.mi8.com (d01gw04.mi8.com [63.240.6.44]) by svr1.postgresql.org (Postfix) with ESMTP id B8556DB86B for ; Tue, 15 Nov 2005 14:42:53 -0400 (AST) Received: from 172.16.1.112 by mail.mi8.com with ESMTP (- Welcome to Mi8 Corporation www.Mi8.com (D4)); Tue, 15 Nov 2005 13:42:46 -0500 X-Server-Uuid: C8FB4D43-1108-484A-A898-3CBCC7906230 Received: from MI8NYCMAIL06.Mi8.com ([172.16.1.175]) by D01SMTP02.Mi8.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Nov 2005 13:42:23 -0500 Received: from 67.103.45.218 ([67.103.45.218]) by MI8NYCMAIL06.Mi8.com ( [172.16.1.219]) via Exchange Front-End Server mi8owa.mi8.com ( [172.16.1.105]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Nov 2005 13:42:22 -0500 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 15 Nov 2005 10:42:22 -0800 Subject: Re: Performance PG 8.0 on dual opteron / 4GB / 3ware From: "Luke Lonergan" To: "Joost Kraaijeveld" , "Dave Cramer" cc: "Pgsql-Performance" Message-ID: Thread-Topic: [PERFORM] Performance PG 8.0 on dual opteron / 4GB / 3ware Thread-Index: AcXqBJN/YAdpHf0pTdG90SDRQNurAQAD7z3D In-Reply-To: <1132072542.3250.16.camel@Panoramix> MIME-Version: 1.0 X-OriginalArrivalTime: 15 Nov 2005 18:42:23.0641 (UTC) FILETIME=[516F2090:01C5EA14] X-WSS-ID: 6F64F3AF31S11621008-09-01 Content-Type: multipart/alternative; boundary=B_3214896142_20825174 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=1.254 required=5 tests=[HTML_MESSAGE=0.001, RCVD_NUMERIC_HELO=1.253] X-Spam-Score: 1.254 X-Spam-Level: * X-Archive-Number: 200511/253 X-Sequence-Number: 15510 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3214896142_20825174 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Joost, On 11/15/05 8:35 AM, "Joost Kraaijeveld" 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 =B3dd bigfile=B2 test with. You should run =B3dd if=3D/dev/zero of=3Dbigfile bs=3D8k count=3D500000=B2 for a 2GB main memory machine, multiply the count by (/2GB). It is very important with the 3Ware cards to match the driver to the firmware revision. =20 > I did notice that changing the I/O scheduler's nr_request from the > 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. >=20 You could try deadline, there=B9s no harm, but I=B9ve found that when you reach the point of experimenting with schedulers, you are probably not addressing the real problem. >=20 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=3Dfalse, 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 th= e 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 =B3dd bigfile=B2 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). =20 Regards, - Luke --B_3214896142_20825174 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Re: [PERFORM] Performance PG 8.0 on dual opteron / 4GB / 3ware</TITL= E> </HEAD> <BODY> Joost= , On 11/15/05 8:35 AM, "Joost Kraaijeveld" <J.Kraaijeveld@Askesi= s.nl> wrote: <BLOCKQUOTE>thousand go relatively fast, after that PostgreSQL craw= ls to a halt (other "benchmarks" like bonnie++ or just dd'ing a big file don't= have this behavior). </BLOCKQUOTE> With RAID5, it could matter a lot what block size you run your “dd bi= gfile” test with. You should run “dd if=3D/dev/zero of=3Dbigfi= le bs=3D8k count=3D500000” for a 2GB main memory machine, multiply the cou= nt by (<your mem>/2GB). It is very important with the 3Ware cards to match the driver to the firmwa= re revision. <BLOCKQUOTE>I did notice that changing the I/O scheduler's nr_reque= st from the 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. </BLOCKQUOTE>You could try deadline, there’s no harm, but I&#= 8217;ve found that when you reach the point of experimenting with schedulers= , you are probably not addressing the real problem. <BLOCKQUOTE> </BLOCKQUOTE>On a 3Ware 9500 with HW RAID5 and 4 or more disks I th= ink you should get 100MB/s write rate, which is double what Postgres can use= . We find that Postgres, even with fsync=3Dfalse, 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 w= riting is about 4-5X more than the net write speed, or the speed at w= hich 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 re= adahead to 8MB or more is extremely beneficial for performance with the 3War= e cards (and with others, but especially for the older 3Ware cards). Regards, - Luke </BODY> </HTML> --B_3214896142_20825174--