Re: Very slow planning performance on partition table

From: Rural Hunter <ruralhunter(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Very slow planning performance on partition table
Date: 2014-07-30 01:13:40
Message-ID: 53D846C4.3020503@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin 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.

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Rural Hunter 2014-07-30 04:05:25 Re: Very slow planning performance on partition table
Previous Message Jeff Janes 2014-07-29 17:27:11 Re: Very slow planning performance on partition table

Browse pgsql-performance by date

  From Date Subject
Next Message Mark Kirkwood 2014-07-30 01:44:54 Re: 60 core performance with 9.3
Previous Message Jeff Janes 2014-07-29 18:36:32 Re: Cursor + upsert (astronomical data)