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 по дате отправления: