Re: Monitoring PostgreSQL connections using cricket and - Mailing list pgsql-general

From Steve Crawford
Subject Re: Monitoring PostgreSQL connections using cricket and
Date
Msg-id 43BD433B.4070105@pinpointresearch.com
Whole thread Raw
In response to Monitoring PostgreSQL connections using cricket and pg_stat_activity  (Tony Wasson <ajwasson@gmail.com>)
Responses Re: Monitoring PostgreSQL connections using cricket and  (Tony Wasson <ajwasson@gmail.com>)
List pgsql-general
> Resting Connections - connections that have no query information. I
> suspect these are connections starting up or shutting down, but feel
> free to clue me in.

OK, this appears to be version-dependent but it can mean that
stats_query_string is false or that the user you are connecting as has
no permission to see the query of the other user.

> I thought about graphing the number of SELECTs/INSERTS/UPDATEs/DELETEs
> currently running. If anyone is interested, I think it would be easy
> to handle.

Each time you run your script you will only have a snapshot at that
instant. It might provide minimally useful information to someone who is
clear about what they are seeing but that snapshot could show a
connection as idle even though it is handling hundreds of small queries
per minute or a connection as running a query even though it sits idle
in a connection pool nearly all the time.

It certainly won't tell you the server-load (you didn't claim it would,
of course). A single huge or badly-written query can hose a server while
piles of quick queries will hardly load it at all.

A snapshot showing a large number of running queries may even be fine if
they are all backed up waiting for a few-second-long table-lock to be
released.

For finding potential problems you should consider looking for "idle in
transaction" queries - especially any that are aging as they can
indicate that something has failed to commit or rollback a transaction.
This can be especially bad on a pool-connection. Until the transaction
is closed, locks can remain in place and start to cause all sorts of
trouble.

Cheers,
Steve

pgsql-general by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: 'Official' definition of ACID compliance?
Next
From: "Tadej Kanizar"
Date:
Subject: Getting timestamp without milliseconds