From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Stanier <alexander.stanier@egsgroup.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Heavy virtual memory usage on production system
Date: Wed, 06 Jul 2005 10:15:33 -0400
Message-ID: <25886.1120659333@sss.pgh.pa.us> (raw)
In-Reply-To: <42CBC8A0.4070901@egsgroup.com>
References: <42CAB1B6.50201@egsgroup.com>
<23889.1120582516@sss.pgh.pa.us>
<42CBC8A0.4070901@egsgroup.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, alexander.stanier@egsgroup.com
Subject: Re: Heavy virtual memory usage on production system
In-Reply-To: <25886.1120659333@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox