Re: Determining server load - Mailing list pgsql-general

From Israel Brewster
Subject Re: Determining server load
Date
Msg-id 29EB0A09-5957-4374-AFB3-9663117D6E83@ravnalaska.net
Whole thread Raw
In response to Re: Determining server load  (John R Pierce <pierce@hogranch.com>)
Responses Re: Determining server load  (Adrian Klaver <adrian.klaver@aklaver.com>)
List pgsql-general
On Sep 27, 2016, at 9:55 AM, John R Pierce <pierce@hogranch.com> wrote:
>
> On 9/27/2016 9:54 AM, Israel Brewster wrote:
>>
>> I did look at pgbadger, which tells me I have gotten as high as 62 connections/second, but given that most of those
connectionsare probably very short lived that doesn't really tell me anything about concurrent connections. 
>
> Each connection requires a process fork of the database server, which is very expensive.  you might consider using a
connectionpool such as pgbouncer, to maintain a fixed(dynamic) number of real database connections, and have your apps
connect/disconnectto this pool.    Obviously, you need a pool for each database, and your apps need to be 'stateless'
andnot make or rely on any session changes to the connection so they don't interfere with each other.   Doing this
correctlycan make an huge performance improvement on the sort of apps that do (connect, transaction, disconnect) a lot. 

Understood. My main *performance critical* apps all use an internal connection pool for this reason - Python's psycopg2
pool,to be exact. I still see a lot of connects/disconnects, but I *think* that's psycopg2 recycling connections in the
background- I'm not 100% certain how the pools there work (and maybe they need some tweaking as well, i.e. setting to
re-useconnections more times or something). The apps that don't use pools are typically data-gathering scripts where it
doesn'tmater how long it takes to connect/write the data (within reason). 

That said, it seems highly probable, if not a given, that there comes a point where the overhead of handling all those
connectionsstarts slowing things down, and not just for the new connection being made. How to figure out where that
pointis for my system, and how close to it I am at the moment, is a large part of what I am wondering. 

Note also that I did realize I was completely wrong about the initial issue - it turned out it was a network issue, not
apostgresql one. Still, I think my specific questions still apply, if only in an academic sense now :-) 

-----------------------------------------------
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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general



pgsql-general by date:

Previous
From: Jonathan Vanasco
Date:
Subject: Re: bitwise storage and operations
Next
From: Igor Neyman
Date:
Subject: Re: isnull() function in pgAdmin3