To: "Luke Lonergan" <llonergan@greenplum.com>
cc: "Gavin Hamill" <gdh@laterooms.com>, pgsql-performance@postgresql.org
Subject: Re: pg 8.1.3, AIX, huge box, painfully slow. 
In-reply-to: <C05C3C44.211A5%llonergan@greenplum.com> 
References: <C05C3C44.211A5%llonergan@greenplum.com>
Comments: In-reply-to "Luke Lonergan" <llonergan@greenplum.com>
	message dated "Fri, 07 Apr 2006 15:56:52 -0700"
Date: Fri, 07 Apr 2006 19:05:38 -0400
Message-ID: <17613.1144451138@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Luke Lonergan" <llonergan@greenplum.com> writes:
> On 4/7/06 3:27 PM, "Gavin Hamill" <gdh@laterooms.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