Re: query against pg_locks leads to large memory alloc
| От | Dave Owens |
|---|---|
| Тема | Re: query against pg_locks leads to large memory alloc |
| Дата | |
| Msg-id | CA+OQrzg0OwnU4TyMnwi577M7aCrNjBb0ObJoyZW+ndUWjmOEgg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: query against pg_locks leads to large memory alloc (Kevin Grittner <kgrittn@ymail.com>) |
| Ответы |
Re: query against pg_locks leads to large memory alloc
|
| Список | pgsql-performance |
I now have 8 hours worth of snapshots from pg_stat_activity and
pg_locks (16 snapshots from each table/view). I have turned off
collection at this point, but I am still able to query pg_locks:
# SELECT mode, count(mode) AS count FROM pg_locks GROUP BY mode ORDER BY mode;
mode | count
------------------+---------
AccessShareLock | 291
ExclusiveLock | 19
RowExclusiveLock | 4
RowShareLock | 1
SIReadLock | 7287531
(5 rows)
SIReadLocks continue to grow. It seems, in general, that our
application code over uses Serializable... we have produced a patch
that demotes some heavy-hitting queries down to Read Committed, and we
will see if this makes an impact on the number of SIReadLocks.
Is it interesting that only 101557 out of 7 million SIReadLocks have a
pid associated with them?
-Dave Owens
В списке pgsql-performance по дате отправления: