Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Z5dQh-00059a-Mi for pgsql-general@arkaria.postgresql.org; Thu, 18 Jun 2015 17:16:43 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Z5dQh-00019d-43 for pgsql-general@arkaria.postgresql.org; Thu, 18 Jun 2015 17:16:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Z5dQf-00019S-JX; Thu, 18 Jun 2015 17:16:41 +0000 Received: from proofpoint2.mail.rice.edu ([128.42.201.101] helo=pp2.rice.edu) by magus.postgresql.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1Z5dQW-000095-7R; Thu, 18 Jun 2015 17:16:40 +0000 Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id t5IHGSdl024524; Thu, 18 Jun 2015 12:16:28 -0500 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp2.rice.edu with ESMTP id 1v3gc2ger1-1; Thu, 18 Jun 2015 12:16:27 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel X-SMTP-Auth: no X-SMTP-Auth: no X-SMTP-Auth: no Received: from aart.rice.edu (aart.rice.edu [168.7.56.48]) by mh2.mail.rice.edu (Postfix) with ESMTP id DD405500116; Thu, 18 Jun 2015 12:16:23 -0500 (CDT) Received: by aart.rice.edu (Postfix, from userid 18612) id D4225100828; Thu, 18 Jun 2015 12:16:23 -0500 (CDT) Date: Thu, 18 Jun 2015 12:16:23 -0500 From: "ktm@rice.edu" To: "Sheena, Prabhjot" Cc: "pgsql-performance@postgresql.org" , "pgsql-general@postgresql.org" Subject: Re: [PERFORM] PGBOUNCER ISSUE PLEASE HELP(Slowing down the site) Message-ID: <20150618171623.GT31129@aart.rice.edu> References: <13E39D789E19FF4E9A87F6D456F3F9820123C607@SEAMBX02.sea.corp.int.untd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13E39D789E19FF4E9A87F6D456F3F9820123C607@SEAMBX02.sea.corp.int.untd.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=9.99200722162641e-16 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.999147469938476 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.999147469938476 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.999147469938476 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1506180287 X-Pg-Spam-Score: -2.9 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-general Precedence: bulk Sender: pgsql-general-owner@postgresql.org On Thu, Jun 18, 2015 at 05:09:10PM +0000, Sheena, Prabhjot wrote: > Guys > I have an issue going on with PGBOUNCER which is slowing down the site > > PGBOUNCER VERSION: pgbouncer-1.5.4-2.el6 (Hosted on separate machine) (16 cpu) 98GB RAM > DATABASE VERION: postgresql 9.3 > > When the total client connections to pgbouncer are close to 1000, site application works fine but when the total client connections crosses 1150 site application starts showing slowness. > > Here is an example of output > > postgres@symds-pg:~ $ netstat -atnp | grep 5432 | wc > (Not all processes could be identified, non-owned process info > will not be shown, you would have to be root to see it all.) > 960 6720 104640 > > > As you can see total connections are like 960 right now my site application is working fine. When connections crosses 1150 and even though I see lot of available connections coz my default_pool_size is set high to 250 but still the application gets slow. Database performance on the other end is great with no slow running queries or anything. So the only place I can think the issue is at PGBOUNCER end. > Hi Prabhjot, This is classic behavior when you have a 1024 file limit. When you are below that number, it work fine. Above that number, you must wait for a connection to close and exit before you can connect which will cause a delay. See what ulimit has to say? Regards, Ken -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general