From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alexander Stanier <alexander(dot)stanier(at)egsgroup(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Heavy virtual memory usage on production system |
Date: | 2005-07-06 14:15:33 |
Message-ID: | 25886.1120659333@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Alexander Stanier <alexander(dot)stanier(at)egsgroup(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Stanier | 2005-07-06 14:49:40 | Re: Heavy virtual memory usage on production system |
Previous Message | Alexander Stanier | 2005-07-06 12:03:44 | Re: Heavy virtual memory usage on production system |