Re: Very slow planning performance on partition table - Mailing list pgsql-performance

From Rural Hunter
Subject Re: Very slow planning performance on partition table
Date
Msg-id 53D846C4.3020503@gmail.com
Whole thread Raw
In response to Re: Very slow planning performance on partition table  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-performance
在 2014/7/30 1:27, Jeff Janes 写道:
>
>
> It sounds like someone is bypassing your pgbouncer and connecting
> directly to your database.  Maybe they tried to create their own
> parallelization and have a master connection going through pgbouncer
> and create many auxiliary connections that go directly to the database
> (probably because pgbouncer wouldn't let them create as many
> connections as they wanted through it).  That would explain why the
> connections slowly drain away once pgbouncer is shut down.
>
> Can you change your pg_hba.conf file so that it only allows
> connections from pgbouncer's IP address?  This should flush out the
> culprit pretty quickly.
>
> Cheers,
>
> Jeff
I suspected that first. But after I checked a few things, I am quite
sure this is not someone bypassing the pgbouncer.
1. The connections were all from the host of pgbouncer.
2. The id is an application id and no human has access to it. There was
no other suspect applications running on the host of pgbouncer when the
problem happened.
3. When I found the problem and checked the connections on the host of
pgbouncer, those network connection actually didn't exist on the client
side while they were still hanging at pg server side.


pgsql-performance by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Cursor + upsert (astronomical data)
Next
From: Mark Kirkwood
Date:
Subject: Re: 60 core performance with 9.3