Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id B0402633762 for ; Mon, 11 Jan 2010 13:13:38 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 00845-06 for ; Mon, 11 Jan 2010 17:13:28 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mail.postgresql.org (Postfix) with ESMTP id F159A632EA0 for ; Mon, 11 Jan 2010 13:13:27 -0400 (AST) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NUNpR-000566-Sx for pgsql-performance@postgresql.org; Mon, 11 Jan 2010 18:13:21 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Jan 2010 18:13:21 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Jan 2010 18:13:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-performance@postgresql.org From: Ivan Voras Subject: Re: performance config help Date: Mon, 11 Jan 2010 18:12:59 +0100 Lines: 68 Message-ID: References: <61039b861001110544o2c352763q13dcf9d78a156714@mail.gmail.com> <61039b861001110842g15bb1f26jc50b6e6762e01427@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.23 (X11/20091210) In-Reply-To: <61039b861001110842g15bb1f26jc50b6e6762e01427@mail.gmail.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.589 tagged_above=-10 required=5 tests=BAYES_00=-2.599, FH_DATE_PAST_20XX=3.188 X-Spam-Level: X-Archive-Number: 201001/193 X-Sequence-Number: 37073 Bob Dusek wrote: > On Mon, Jan 11, 2010 at 8:50 AM, Scott Marlowe > wrote: > > On Mon, Jan 11, 2010 at 6:44 AM, Bob Dusek > wrote: > > Hello, > > > > We're running Postgres 8.4.2 on Red Hat 5, on pretty hefty > hardware... > > > > 4X E7420 Xeon, Four cores (for a total of 16 cores) > > 2.13 GHz, 8M Cache, 1066 Mhz FSB > > 32 Gigs of RAM > > 15 K RPM drives in striped raid > > What method of striped RAID? RAID-5? RAID-10? RAID-4? RAID-0? > > > RAID-0 And how many drives? > > > Things run fine, but when we get a lot of concurrent queries > running, we see > > a pretty good slow down. > > Definte "a lot". > > > We have an application server that is processing requests. Each request > consists of a combination of selects, inserts, and deletes. We actually > see degredation when we get more than 40 concurrent requests. The exact > number of queries executed by each request isn't known. It varies per > request. But, an example request would be about 16 inserts and 113 > selects. Any given request can't execute more than a single query at a > time. So, you are concurrently trying to achieve more than around 640 writes and 4520 reads (worst case figures...). This should be interesting. For 40 concurrent requests you will probably need at least 4 drives in RAID-0 to sustain the write rates (and I'll guess 5-6 to be sure to cover read requests also, together with plenty of RAM). > avg-cpu: %user %nice %system %iowait %steal %idle > 34.29 0.00 7.09 0.03 0.00 58.58 > > Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz > avgqu-sz await svctm %util > sda 0.00 112.20 0.00 133.40 0.00 1964.80 > 14.73 0.42 3.17 0.04 0.48 > > The iowait seems pretty low, doesn't it? Yes, but you are issuing 133 write operations per seconds per drive(s) - this is nearly the limit of what you can get with 15k RPM drives (actually, the limit should be somewhere around 200..250 IOPS but 133 isn't that far). > top - 10:11:43 up 12 days, 20:48, 6 users, load average: 10.48, 4.16, 2.83 > Tasks: 798 total, 8 running, 790 sleeping, 0 stopped, 0 zombie > Cpu0 : 33.3%us, 7.6%sy, 0.0%ni, 59.1%id, 0.0%wa, 0.0%hi, 0.0%si, > 0.0%st There is one other possibility - since the CPUs are not very loaded, are you sure the client application with which you are testing is fast enough to issue enough request to saturate the database?