Re: Heavy virtual memory usage on production system
| От | Tom Lane |
|---|---|
| Тема | Re: Heavy virtual memory usage on production system |
| Дата | |
| Msg-id | 25886.1120659333@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Heavy virtual memory usage on production system (Alexander Stanier <alexander.stanier@egsgroup.com>) |
| Ответы |
Re: Heavy virtual memory usage on production system
|
| Список | pgsql-performance |
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
В списке pgsql-performance по дате отправления: