X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 9EC9552AFE for ; Thu, 11 Aug 2005 10:19:30 -0300 (ADT) 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 99406-05 for ; Thu, 11 Aug 2005 13:19:25 +0000 (GMT) Received: from mail.tecarta.com (66.238.115.135.ptr.us.xo.net [66.238.115.135]) by svr1.postgresql.org (Postfix) with ESMTP id 5E93652AE5 for ; Thu, 11 Aug 2005 10:19:24 -0300 (ADT) Received: from mail pickup service by mail.tecarta.com with Microsoft SMTPSVC; Thu, 11 Aug 2005 06:23:13 -0700 Received: from mail.tecarta.com ([192.168.160.2]) by mail.tecarta.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Aug 2005 06:23:09 -0700 Received: from barracuda.tecarta.com ([192.168.160.200]) by mail.tecarta.com (SAVSMTP 3.1.0.29) with SMTP id M2005081106230901800 for ; Thu, 11 Aug 2005 06:23:09 -0700 X-ASG-Debug-ID: 1123766364-13015-0-0 X-Barracuda-URL: http://192.168.160.200:8000/cgi-bin/mark.cgi Received: from mail1 (mail1.hq.corp [192.168.160.5]) by barracuda.tecarta.com (Spam Firewall) with SMTP id 1BD2D20171B3 for ; Thu, 11 Aug 2005 06:19:24 -0700 (PDT) Received: from [192.168.0.100] ([63.206.203.145]) by mail.tecarta.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Aug 2005 06:23:02 -0700 X-ASG-Orig-Subj: Re: [PERFORM] PG8 Tuning Subject: [SPAM?] Re: PG8 Tuning From: Steve Poe To: paul@oxton.com Cc: pgsql-performance@postgresql.org In-Reply-To: <1536.217.45.209.171.1123763001.squirrel@www.gradwell.com> References: <1536.217.45.209.171.1123763001.squirrel@www.gradwell.com> Content-Type: text/plain Date: Fri, 12 Aug 2005 08:47:08 +0000 Message-Id: <1123836428.19976.26.camel@amd64-laptop-spoe> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Aug 2005 13:23:02.0302 (UTC) FILETIME=[CCBAD3E0:01C59E77] X-Virus-Scanned: by Barracuda Spam Firewall at tecarta.com X-Barracuda-Spam-Score: 4.03 X-Barracuda-Spam-Status: Yes, SCORE=4.03 using global scores of TAG_LEVEL=4.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=7.0 tests=BAYES_60, DATE_IN_FUTURE_12_24 X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.3136 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 3.03 DATE_IN_FUTURE_12_24 Date: is 12 to 24 hours after Received: date 1.00 BAYES_60 BODY: Bayesian spam probability is 60 to 80% [score: 0.6148] X-Priority: 5 (Lowest) X-MSMail-Priority: Low Importance: Low X-Barracuda-Spam-Flag: YES X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.329 tagged_above=0 required=5 tests=[AWL=-1.050, DATE_IN_FUTURE_12_24=2.329, FORGED_RCVD_HELO=0.05, MISSING_MIMEOLE=0] X-Spam-Level: * X-Archive-Number: 200508/120 X-Sequence-Number: 13867 Paul, Before I say anything else, one online document which may be of assistance to you is: http://www.powerpostgresql.com/PerfList/ Some thoughts I have: 3) You're shared RAM setting seems overkill to me. Part of the challenge is you're going from 1000 to 262K with no assessment in between. Each situation can be different, but try in the range of 10 - 50K. 4) pg_xlog: If you're pg_xlog is on a spindle is *only* for pg_xlog you're better off. If it is sharing with any other OS/DB resource, the performance will be impacted. From what I have learned from others on this list, RAID5 is not the best choice for the database. RAID10 would be a better solution (using 8 of your disks) then take the remaining disk and do mirror with your pg_xlog if possible. Best of luck, Steve Poe On Thu, 2005-08-11 at 13:23 +0100, Paul Johnson wrote: > Hi all, we're running PG8 on a Sun V250 with 8GB RAM and 2*1.3GHz SPARC > CPUs running Solaris 10. The DB cluster is on an external fibre-attached > Sun T3 array that has 9*36GB drives configured as a single RAID5 LUN. > > The system is for the sole use of a couple of data warehouse developers, > hence we are keen to use 'aggressive' tuning options to maximise > performance. > > So far we have made the following changes and measured the impact on our > test suite: > > 1) Increase checkpoint_segments from 3 to 64. This made a 10x improvement > in some cases. > > 2) Increase work_mem from 1,024 to 524,288. > > 3) Increase shared_buffers from 1,000 to 262,143 (2 GB). This required > setting SHMMAX=4294967295 (4 GB) in /etc/system and re-booting the box. > > Question - can Postgres only use 2GB RAM, given that shared_buffers can > only be set as high as 262,143 (8K pages)? > > So far so good... > > 4) Move /pg_xlog to an internal disk within the V250. This has had a > severe *negative* impact on performance. Copy job has gone from 2 mins to > 12 mins, simple SQL job gone from 1 min to 7 mins. Not even run long SQL > jobs. > > I'm guessing that this is because pg_xlog has gone from a 9 spindle LUN to > a single spindle disk? > > In cases such as this, where an external storage array with a hardware > RAID controller is used, the normal advice to separate the data from the > pg_xlog seems to come unstuck, or are we missing something? > > Cheers, > > Paul Johnson. > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org