Re: Very slow planning performance on partition table

Поиск
Список
Период
Сортировка
От Rural Hunter
Тема Re: Very slow planning performance on partition table
Дата
Msg-id 53D846C4.3020503@gmail.com
обсуждение исходный текст
Ответ на Re: Very slow planning performance on partition table  (Jeff Janes <jeff.janes@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: Cursor + upsert (astronomical data)
Следующее
От: Mark Kirkwood
Дата:
Сообщение: Re: 60 core performance with 9.3