From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Ivan Voras <ivoras(at)freebsd(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Performance under contention |
Date: | 2010-12-06 19:07:05 |
Message-ID: | AANLkTi=FosOakJr84x5pchZ65Fi9Gt4yqcsvSHTazLyR@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, Dec 6, 2010 at 12:10 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sun, Nov 21, 2010 at 7:15 PM, Ivan Voras <ivoras(at)freebsd(dot)org> wrote:
>> The "sbwait" part is from FreeBSD - IPC sockets, but so much blocking on
>> semwait indicates large contention in PostgreSQL.
>
> I can reproduce this. I suspect, but cannot yet prove, that this is
> contention over the lock manager partition locks or the buffer mapping
> locks.
I compiled with LWLOCK_STATS defined and found that exactly one lock
manager partition lwlock was heavily contended, because, of course,
the SELECT-only test only hits one table, and all the threads fight
over acquisition and release of AccessShareLock on that table. One
might argue that in more normal workloads there will be more than one
table involved, but that's not necessarily true, and in any case there
might not be more than a handful of major ones.
However, I don't have a very clear idea what to do about it.
Increasing the number of lock partitions doesn't help, because the one
table you care about is still only in one partition.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | bricklen | 2010-12-06 19:46:04 | Re: Update problem on large table |
Previous Message | Tom Lane | 2010-12-06 18:03:44 | Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT |