Postgres Pro
Downloads
Home   >   mailing lists

Thread: Lock Statistics

Lock Statistics

From
"Milen A. Radev"
Date:
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

Re: Lock Statistics

From
adey
Date:
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 c

where l.pid = s. procpid

and l.relation = c .relfilenode

and s.usesysid = u .usesysid

order 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

Re: Lock Statistics

From
Michael Fuhr
Date:
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

Re: Lock Statistics

From
Michael Fuhr
Date:
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

Re: Lock Statistics

From
adey
Date:


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