| From: | Dave Owens <dave(at)teamunify(dot)com> |
|---|---|
| To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Matheus de Oliveira <matioli(dot)matheus(at)gmail(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: query against pg_locks leads to large memory alloc |
| Date: | 2014-08-20 17:15:45 |
| Message-ID: | CA+OQrzg0OwnU4TyMnwi577M7aCrNjBb0ObJoyZW+ndUWjmOEgg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2014-08-20 18:15:02 | Re: query against pg_locks leads to large memory alloc |
| Previous Message | Tom Lane | 2014-08-20 14:12:48 | Re: query on parent partition table has bad performance |