From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
Cc: | "Gavin Hamill" <gdh(at)laterooms(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: pg 8.1.3, AIX, huge box, painfully slow. |
Date: | 2006-04-07 23:05:38 |
Message-ID: | 17613.1144451138@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"Luke Lonergan" <llonergan(at)greenplum(dot)com> writes:
> On 4/7/06 3:27 PM, "Gavin Hamill" <gdh(at)laterooms(dot)com> wrote:
>> 278774: __semop(15728650, 0x0FFFFFFFFFFF7E80, 1) = 0
>> 155712: __semop(15728650, 0x0FFFFFFFFFFF5920, 1) = 0
>> 278774: __semop(15728649, 0x0FFFFFFFFFFF6F10, 1)
> Seems like you're hitting a very small target in RAM with these semop calls.
IIRC the address passed to semop() in our code is always a local struct
on the stack, so that's a bit of a red herring --- there won't be
cross-processor contention for that.
It's plausible though that we are seeing contention across members of
the LWLock array, with the semop storm just being a higher-level symptom
of the real hardware-level problem. You might try increasing
LWLOCK_PADDED_SIZE to 64 or even 128, see
src/backend/storage/lmgr/lwlock.c (this is something that does exist in
8.1, so it'd be easy to try).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Hamill | 2006-04-07 23:39:19 | Re: pg 8.1.3, AIX, huge box, painfully slow. |
Previous Message | Luke Lonergan | 2006-04-07 22:56:52 | Re: pg 8.1.3, AIX, huge box, painfully slow. |