My guess would be that your server upgrade wasn't the upgrade you thought
it was.
You network latency could definitely be the cause of most of this. The
problem is you're not measuring this from the server side. It's not only
going to impact connect time, but you're going to get your data a bit
sl
My guess is you are hitting an open file ulimit. Add ulimit -n 5 to
the start of whatever you use to start pgbouncer (init script, etc..)
On Thu, Jun 18, 2015 at 1:10 PM Sheena, Prabhjot <
prabhjot.si...@classmates.com> wrote:
> Guys
>
> I have an issue going on with PGBOUNCER whic
In New Relic, go back a half hour before the problem started so you can't
see that this spike happened and send the same screenshot in. My guess is
you have increased activity hitting the DB. Do you have pgbouncer or some
kind of connection pooling sitting in front? 198 open server connections
coul
> We will probably tweak this knob some more -- i.e., what is the sweet spot
> between 1 and 100? Would it be higher than 50 but less than 100? Or is it
> somewhere lower than 50?
>
>
I would love to know the answer to this as well. We have a similar situation,
pgbouncer with transaction log
Clients are technically our pgbouncer which is on the same machine. The explain
analyze was local through psql direct to postgresql.
On Wednesday, February 6, 2013 at 11:22 AM, Kevin Grittner wrote:
> Will Platnick mailto:wplatn...@gmail.com)> wrote:
> > Will Platnick m
Good eye, I totally missed that!
Any ideas on how to troubleshoot this delay?
On Wednesday, February 6, 2013 at 3:51 AM, Pavan Deolasee wrote:
> On Tue, Feb 5, 2013 at 9:15 AM, Will Platnick (mailto:wplatn...@gmail.com)> wrote:
> > We upgraded from PG 9.1 to 9.2. Since the
ail_index" UNIQUE, btree (lower(email::text))
"u_auth_uname_index" UNIQUE, btree (lower(username::text))
"u_auth_verify_hash_idx" UNIQUE, btree (verify_hash)
"users_search_updated_dt_idx" btree (search_updated_dt DESC)
--
Will Platnick
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
