| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Andrew Dunstan <andrew(dot)dunstan(at)pgexperts(dot)com> |
| Cc: | pgsql-perform <pgsql-performance(at)postgresql(dot)org> |
| Subject: | backend suddenly becomes slow, then remains slow |
| Date: | 2012-12-27 04:03:33 |
| Message-ID: | CAMkU=1xaOiD2KwBDFjfdnFGaLMc1SCR90y-2kSJuvM_T-zexEg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Fri, Dec 14, 2012 at 10:40 AM, Andrew Dunstan <
andrew(dot)dunstan(at)pgexperts(dot)com> wrote:
> 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.
By "no spike", do you mean that the system as a whole is not using an
unusual amount of IO or CPU, or that this specific slow back-end is not
using an unusual amount?
Could you strace is and see what it is doing?
> 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.
Do you have a huge number of tables? Maybe over the course of a long-lived
connection, it touches enough tables to bloat the relcache / syscache. I
don't know how the autovac would be involved in that, though.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2012-12-27 04:03:35 | Re: Why does the query planner use two full indexes, when a dedicated partial index exists? (solved?) |
| Previous Message | Jeff Janes | 2012-12-27 04:03:32 | Re: Why does the query planner use two full indexes, when a dedicated partial index exists? |