Обсуждение: Lock Statistics
I have performance problems with a DB (slow queries) and I suspect the main cause is that a lot of queries wait for a lock on one small table. That's why I need some stats about the number and (average) wait-time for locks (even only for this particular table). After a bit of googling I found a project in PgFoundry with a promising description - http://pgfoundry.org/projects/pglockdiag/. Unfortunately the projects seems stillborn - no published files and nothing in CVS. -- Milen A. Radev
Try this query for a start, and add system tables to the join to find what you want:-
-- displays locks with database name and username, but not table
-- CAUTION: this query may impact system performance as you are selecting from system tables
select
relation
,
c.relname,
u.usename,
pid,
mode,
transaction,
granted,
datname,
u.usesysid,
usesuper--*
from
pg_locks l, pg_stat_activity s, pg_user u , pg_class cwhere
l.pid = s. procpid and l.relation = c .relfilenode and s.usesysid = u .usesysidorder
by l.pid;On 7/31/07, Milen A. Radev <milen@radev.net> wrote:
I have performance problems with a DB (slow queries) and I suspect the
main cause is that a lot of queries wait for a lock on one small
table. That's why I need some stats about the number and (average)
wait-time for locks (even only for this particular table).
After a bit of googling I found a project in PgFoundry with a
promising description - http://pgfoundry.org/projects/pglockdiag/.
Unfortunately the projects seems stillborn - no published files and
nothing in CVS.
--
Milen A. Radev
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
On Mon, Jul 30, 2007 at 07:11:11PM +0300, Milen A. Radev wrote: > I have performance problems with a DB (slow queries) and I suspect the > main cause is that a lot of queries wait for a lock on one small > table. That's why I need some stats about the number and (average) > wait-time for locks (even only for this particular table). Why do you suspect that locks are the problem? Unless the queries are making concurrent updates of the same row(s) locking isn't likely to be the problem due to the way MVCC works. Could you post one of the slow queries along with the EXPLAIN ANALYZE output? Are you vacuuming and analyzing your tables regularly? What version of PostgreSQL are you running? PostgreSQL 8.3 will have a log_lock_waits configuration setting to log locks that wait longer than deadlock_timeout but that doesn't help you now unless you're able and willing to run tests in a version of PostgreSQL that's still under development (don't use it for anything you wouldn't want to lose). -- Michael Fuhr
On Tue, Jul 31, 2007 at 10:35:25AM +1200, adey wrote: > -- CAUTION: this query may impact system performance as you are selecting > from system tables What difference are you expecting that to make and why? -- Michael Fuhr
On 7/31/07, Michael Fuhr <mike@fuhr.org> wrote:
On Tue, Jul 31, 2007 at 10:35:25AM +1200, adey wrote:
> -- CAUTION: this query may impact system performance as you are selecting
> from system tables
What difference are you expecting that to make and why?
It was a warning I received some years ago when I riginally discovered the query. Presumably reading from system tables competes with user queries for the system tables, slowing them down. I can't say I've ever noticed any impact when using it though.
--
Michael Fuhr