From: | Israel Brewster <israel(at)ravnalaska(dot)net> |
---|---|
To: | John R Pierce <pierce(at)hogranch(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Determining server load |
Date: | 2016-09-27 19:22:25 |
Message-ID: | 9738D5C8-F1BA-4144-9087-648853BA7F52@ravnalaska.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sep 27, 2016, at 11:16 AM, John R Pierce <pierce(at)hogranch(dot)com> wrote:
>
> On 9/27/2016 12:06 PM, Israel Brewster wrote:
>> That helps for one-time stat collection, but as I mentioned in my original message, since connections may not last long, I could be getting close to, or even hitting, my connection limit while still getting values back from those that show plenty of connections remaining, depending on how often I checked.
>>
>> I guess what would be ideal in my mind is that whenever Postgresql logged an opened/closed connection, it also looked the *total* number of open connections at that time. I don't think that's possible, however :-)
>
> if you stick pgbouncer in front of postgres (with a pool for each user(at)database), I believe you CAN track the max connections via pgbouncer's pool stats.
Ahh! If so, that alone would be reason enough for using pgbouncer. Thanks!
-----------------------------------------------
Israel Brewster
Systems Analyst II
Ravn Alaska
5245 Airport Industrial Rd
Fairbanks, AK 99709
(907) 450-7293
-----------------------------------------------
>
>
> --
> john r pierce, recycling bits in santa cruz
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2016-09-27 19:54:12 | Re: Update two tables returning id from insert CTE Query |
Previous Message | John R Pierce | 2016-09-27 19:16:47 | Re: Determining server load |