Message-ID: <50CB8913.8050202@dunslane.net>
Date: Fri, 14 Dec 2012 15:16:19 -0500
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-perform <pgsql-performance@postgresql.org>
Subject: Re: backend suddenly becomes slow, then remains slow
References: <50CB7284.3020008@pgexperts.com> <5309.1355514960@sss.pgh.pa.us>
In-Reply-To: <5309.1355514960@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 12/14/2012 02:56 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@pgexperts.com> writes:
>> One of my clients has an odd problem. Every so often a backend will
>> suddenly become very slow. The odd thing is that once this has happened
>> it remains slowed down, for all subsequent queries. Zone reclaim is off.
>> There is no IO or CPU spike, no checkpoint issues or stats timeouts, no
>> other symptom that we can see. The problem was a lot worse that it is
>> now, but two steps have alleviated it mostly, but not completely: much
>> less aggressive autovacuuming and reducing the maximum lifetime of
>> backends in the connection pooler to 30 minutes.
>> It's got us rather puzzled. Has anyone seen anything like this?
> Maybe the kernel is auto-nice'ing the process once it's accumulated X
> amount of CPU time?
>
> 			


That was my initial thought, but the client said not. We'll check again.

cheers

andrew


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance