Re: Monitoring PostgreSQL connections using cricket and
От | Steve Crawford |
---|---|
Тема | Re: Monitoring PostgreSQL connections using cricket and |
Дата | |
Msg-id | 43BD433B.4070105@pinpointresearch.com обсуждение исходный текст |
Ответ на | Monitoring PostgreSQL connections using cricket and pg_stat_activity (Tony Wasson <ajwasson@gmail.com>) |
Ответы |
Re: Monitoring PostgreSQL connections using cricket and
|
Список | 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 по дате отправления: