To: Alexander Stanier <alexander.stanier@egsgroup.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Heavy virtual memory usage on production system 
In-reply-to: <42CBC8A0.4070901@egsgroup.com> 
References: <42CAB1B6.50201@egsgroup.com> <23889.1120582516@sss.pgh.pa.us>
	<42CBC8A0.4070901@egsgroup.com>
Comments: In-reply-to Alexander Stanier <alexander.stanier@egsgroup.com>
	message dated "Wed, 06 Jul 2005 13:03:44 +0100"
Date: Wed, 06 Jul 2005 10:15:33 -0400
Message-ID: <25886.1120659333@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Alexander Stanier <alexander.stanier@egsgroup.com> writes:
> The problem happened again this morning and I took the chance to check 
> out the locking situation. The number of locks increased dramatically up 
> to over 1000, but they were all "AccessShareLocks" and all were granted. 
> The odd "RowExclusiveLock" appeared but none persisted. On the basis 
> that nothing seems to be waiting for a lock, I don't think it is a 
> locking problem.

Hmm.  How many active processes were there, and how many locks per
process?  (A quick "SELECT pid, count(*) GROUP BY pid" query should give
you this info next time.)  We just recently got rid of some O(N^2)
behavior in the lock manager for cases where a single backend holds many
different locks.  So if there's a single query acquiring a whole lot of
locks, that could possibly have something to do with this.

			regards, tom lane