Re: PostgreSQL 9.2.3 performance problem caused Exclusive locks

From: "Emre Hasegeli" <emre(dot)hasegeli(at)tart(dot)com(dot)tr>
To: "AI Rumman" <rummandba(at)gmail(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, "Kevin Grittner" <kgrittn(at)postgresql(dot)org>, "Jan Wieck" <JanWieck(at)yahoo(dot)com>
Subject: Re: PostgreSQL 9.2.3 performance problem caused Exclusive locks
Date: 2013-03-08 19:56:23
Message-ID: op.wtm8cay7k2xoe5@hasegeli.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

On Fri, 08 Mar 2013 20:39:45 +0200, AI Rumman <rummandba(at)gmail(dot)com> wrote:

> Knowing your problem, I read the docs and found that :
> *
> *
>
> *Fix performance problems with autovacuum truncation in busy workloads
> (Jan
> Wieck)*
>
> *Truncation of empty pages at the end of a table requires exclusive lock,
> but autovacuum was coded to fail (and release the table lock) when there
> are conflicting lock requests. Under load, it is easily possible that
> truncation would never occur, resulting in table bloat. Fix by
> performing a
> partial truncation, releasing the lock, then attempting to re-acquire the
> lock and
> continue<http://www.postgresql.org/docs/9.2/static/release-9-2-3.html#>.
> This fix also greatly reduces the average time before autovacuum releases
> the lock after a conflicting request arrives.*
>
> This could be a reason of your locking.

Yes, I saw this. It is commit b19e4250b45e91c9cbdd18d35ea6391ab5961c8d by
Jan Wieck. He also seems worried in the commit message about this patch. Do
you think this is the exact reason of the problem?

I have downgraded to 9.2.2, decreased the autovacuum_max_workers to 2 from
10 and increase max_connections to 500 from 200 in the mean time. There are
not any ExclusiveLock's since then.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bradley Russell 2013-03-08 21:14:25 Re: stored procedure slower when called through c client than pgadmin
Previous Message Pavel Stehule 2013-03-08 17:08:59 Re: stored procedure slower when called through c client than pgadmin

Browse pgsql-performance by date

  From Date Subject
Next Message Carlo Stonebanks 2013-03-08 21:27:54 Re: Are bitmap index scans slow to start?
Previous Message David Leverton 2013-03-08 13:49:56 Re: Poor plan when joining against a union containing a join