Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 1D2AC1337B77 for ; Fri, 28 Jan 2011 10:06:30 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 52830-02 for ; Fri, 28 Jan 2011 14:06:22 +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 853901337B4F for ; Fri, 28 Jan 2011 10:06:21 -0400 (AST) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Pioxv-0003UA-2o for pgsql-performance@postgresql.org; Fri, 28 Jan 2011 15:06:19 +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 ; Fri, 28 Jan 2011 15:06:19 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Jan 2011 15:06:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-performance@postgresql.org From: Ivan Voras Subject: Re: High load, Date: Fri, 28 Jan 2011 15:06:07 +0100 Lines: 17 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: X-Enigmail-Version: 1.1.2 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201101/313 X-Sequence-Number: 42100 On 27/01/2011 11:31, Michael Kohl wrote: > Hi all, > > we are running a fairly big Ruby on Rails application on Postgres 8.4. > Our traffic grew quite a bit lately, and since then we are facing DB > performance issues. System load occasionally explodes (around 170 > yesterday on a 16 core system), which seems to be caused by disk I/O > (iowait in our Munin graphs goes up significantly during these > periods). At other times the laod stays rather low under pretty much > the same circumstances. Is there any way you can moderate the number of total active connections to the database to approximately match the number of (logical) CPU cores on your system? I.e. some kind of connection pool or connection limiting? This should help you in more ways than one (limit PG lock contention, limit parallel disk IO).