backend suddenly becomes slow, then remains slow

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: Raw Message | Whole Thread | 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

In response to

Responses

Browse pgsql-performance by date

  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?