Re: total number of concurrent connections
От | Tom Lane |
---|---|
Тема | Re: total number of concurrent connections |
Дата | |
Msg-id | 1451.1248639806@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | total number of concurrent connections (Lonni J Friedman <netllama@gmail.com>) |
Ответы |
Re: total number of concurrent connections
|
Список | pgsql-novice |
Lonni J Friedman <netllama@gmail.com> writes: > I've got a postgresql-8.1.10 instance running on a Linux system. Over > the weekend it suddenly started rejecting client connection attempts > with a "too many connected" error. ... > The real problem that I'm having is that I can't seem to find any > obvious way to determine what the current number of connections are to > the server. Googling a bit suggests that running "select count(*) > from pg_stat_activity;" would provide the answer, however I'm very > suspicious of the accuracy of the results. pg_stat_activity should be reasonably trustworthy, modulo the fact that the display might be a fraction of a second out-of-date. > especially when I run 'netstat -a | grep -c postgr' and I get 183 back > (granted many are in a TIME_WAIT state, but shouldn't that still count > as a valid connection to the database?). No, it doesn't. That's a recently-dead connection. It may still be of interest to the TCP stack, but Postgres has forgotten about it. > Another thing that makes no sense is why the client_addr is seemingly > null Expected for a Unix-socket connection. I think you've got a lot of extremely transient connections and you just happened to have a burst of them at the same instant. Aside from the question of not being sure where to set max_connections, this is a pretty bad idea from a performance standpoint. PG backends aren't all that lightweight, so it's not good to fire one up for just a single query, which is what it sounds like your app is doing. Consider using a connection pooler. regards, tom lane
В списке pgsql-novice по дате отправления: