Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id D68B16328B6
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri, 25 Jun 2010 13:39:17 -0300 (ADT)
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 06556-07
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri, 25 Jun 2010 16:39:10 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from bunsen.bytemark.co.uk (bunsen.bytemark.co.uk [80.68.81.6])
	by mail.postgresql.org (Postfix) with ESMTP id EED8D6321BE
	for <pgsql-performance@postgresql.org>;
	Fri, 25 Jun 2010 13:39:10 -0300 (ADT)
Received: from tetrarch.vm.bytemark.co.uk ([89.16.174.118]
	helo=mail.audioboundary.com)
	by bunsen.bytemark.co.uk with esmtp (Exim 4.69)
	(envelope-from <tom@audioboundary.com>) id 1OSBvq-0002fo-AG
	for pgsql-performance@postgresql.org; Fri, 25 Jun 2010 17:39:10 +0100
Received: from [192.168.1.66] (93-97-117-199.zone5.bethere.co.uk
	[93.97.117.199])
	by mail.audioboundary.com (Postfix) with ESMTPSA id 0E874E0286
	for <pgsql-performance@postgresql.org>;
	Fri, 25 Jun 2010 17:39:05 +0100 (BST)
Message-ID: <4C24DBA9.7030303@audioboundary.com>
Date: Fri, 25 Jun 2010 17:39:05 +0100
From: Tom Molesworth <tom@audioboundary.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: sudden spurt in swap utilization (was:cpu bound 	postgresql
	setup.)
References: <AANLkTinDBPQL-SjLaCr7AVgzouWbRrjwA6MAgBih_ciy@mail.gmail.com>
	<4C2492F9.2020706@gmail.com>
	<AANLkTikUDoXMF-7N7csuYPWIzn9gSKm_g4NnmjvAYu8N@mail.gmail.com>
	<4C2477A20200002500032B03@gw.wicourts.gov>
	<AANLkTimPhkr2nvuLo-fpBfUdN08KsDFTwzL9ubJP5VG2@mail.gmail.com>
	<AANLkTikJEyqi_8WRI6FjH3OBnnIj4SV9EbTBLl2EGCZw@mail.gmail.com>
In-Reply-To: <AANLkTikJEyqi_8WRI6FjH3OBnnIj4SV9EbTBLl2EGCZw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.8 tagged_above=-10 required=5 tests=BAYES_50=0.8
X-Spam-Level: 
X-Archive-Number: 201006/470
X-Sequence-Number: 39326

On 25/06/10 16:59, Rajesh Kumar Mallah wrote:
> when i reduce max_connections i start getting errors, i will see again 
> concurrent connections
> during business hours. lot of our connections are in <IDLE in 
> transaction state> during business
> this peculiar  behavior of  mod_perl servers have been discussed in 
> past i think. dont' remember
> if there was any resolution.

If connections spend any significant amount of time in <IDLE in 
transaction> state, that might indicate you're not committing/rolling 
back after running queries - can you show an example of the code you're 
using?

e.g. something like my $dbh = DBI->connect(...); my $sth = 
$dbh->prepare(q{select ... }); $sth->fetchall_arrayref; $sth->rollback;

Tom