To: "Donald C. Sumbry ][" <sumbry@revver.com>
cc: pgsql-performance@postgresql.org
Subject: Re: High Context-Switches on Linux 8.1.4 Server 
In-reply-to: <44D7616D.6080906@revver.com> 
References: <44D6EDFA.4030802@revver.com> <19629.1154955137@sss.pgh.pa.us>
	<44D7616D.6080906@revver.com>
Comments: In-reply-to "Donald C. Sumbry ][" <sumbry@revver.com>
	message dated "Mon, 07 Aug 2006 08:51:09 -0700"
Date: Mon, 07 Aug 2006 14:34:41 -0400
Message-ID: <3795.1154975681@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

>> Is this from LWLock or spinlock contention?

> Over a 20 second interval, I've got about 85 select()s and 6,230 
> semop()s. 2604 read()s vs 16 write()s.

OK, so mostly LWLocks then.

>> Do you have any long-running transactions,

> Not long-running.  We do have a badly behaving legacy app that is 
> leaving some backends "idle in transaction"  They're gone pretty quickly 
> so I can't kill them fast enough, but running a pg_stat_activity  will 
> always show at least a handful.  Could this be contributing?

Sorry, I was unclear: it's the age of your oldest transaction that
counts (measured by how many xacts started since it), not how many
cycles it's consumed or not.

With the 8.1 code it's possible for performance to degrade pretty badly
once the age of your oldest transaction exceeds 16K transactions.  You
were not specific enough about the behavior of this legacy app to let
me guess where you are on that scale ...

> Based on the number of semop's we're getting it does look like 
> shared_memory may be getting thrased - any suggestions?  We did try 
> lowering shared_memory usage in half the previous day,

Unlikely to help --- if it is the pg_subtrans problem, the number of
buffers involved is set by a compile-time constant.

			regards, tom lane