From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(dot)dunstan(at)pgexperts(dot)com> |
Cc: | pgsql-perform <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: backend suddenly becomes slow, then remains slow |
Date: | 2012-12-14 19:56:00 |
Message-ID: | 5309.1355514960@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Andrew Dunstan <andrew(dot)dunstan(at)pgexperts(dot)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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Claudio Freire | 2012-12-14 20:10:18 | Re: Why does the number of rows are different in actual and estimated. |
Previous Message | AI Rumman | 2012-12-14 19:28:50 | Re: Why does the number of rows are different in actual and estimated. |