Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 382202E0078 for ; Tue, 22 Apr 2008 13:10:35 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 99386-08 for ; Tue, 22 Apr 2008 13:10:28 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from ironic.cynic.net (125x100x126x243.ap125.ftth.ucom.ne.jp [125.100.126.243]) by developer.postgresql.org (Postfix) with ESMTP id 92C622E007B for ; Tue, 22 Apr 2008 13:10:28 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ironic.cynic.net (Postfix) with ESMTP id 02FE91F88B; Wed, 23 Apr 2008 01:10:27 +0900 (JST) Date: Wed, 23 Apr 2008 01:10:26 +0900 From: Bryan Buecking To: Erik Jones Cc: pgsql-performance@postgresql.org Subject: Re: CPU bound at 99% Message-ID: <20080422161020.GE5961@starling-software.com> References: <20080422153045.GB5961@starling-software.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.6 tagged_above=0 required=5 tests=AWL=0.500, RDNS_DYNAMIC=0.1 X-Spam-Level: X-Archive-Number: 200804/322 X-Sequence-Number: 29815 On Tue, Apr 22, 2008 at 10:55:19AM -0500, Erik Jones wrote: > On Apr 22, 2008, at 10:31 AM, Bryan Buecking wrote: > > >max_connections = 2400 > > That is WAY too high. Get a real pooler, such as pgpool, and drop > that down to 1000 and test from there. I agree, but the number of idle connections dont' seem to affect performace only memory usage. I'm trying to lessen the load of connection setup. But sounds like this tax is minimal? When these issues started happening, max_connections was set to 1000 and I was not using persistent connections. > I see you mentioned 500 concurrent connections. Are each of those > connections actually doing something? Yes out of the 2400 odd connections, 500 are either in SELECT or RESET. > My guess that once you cut down on the number actual connections > you'll find that each connection can get it's work done faster > and you'll see that number drop significantly. I agree, but not in this case. I will look at using pooling. -- Bryan Buecking http://www.starling-software.com