On 7/30/10 10:37 AM, Kevin Grittner wrote:
Craig James<craig_james@xxxxxxxxxxxxxx> wrote:
Well, the "if it ain't broke, don't fix it" rule might come into
play here.
I should have given one more detail here: We've been the victim
of persistent "CPU spikes" that were discussed extensively in
postgres-performance. Tom suggested upgrading to 8.4.4, but that
can't happen for a couple more months (we're working on it).
http://archives.postgresql.org/pgsql-performance/2010-04/msg00071.php
Ah, I hadn't connected that thread with this. After rereading that
thread with the information from this thread in mind, I think what
you describe on the other thread could well be the "thundering herd"
problem. Some form of connection pooling could well help.
BTW, I hope you've updated to the latest 8.3.x by now. If not, you
should expedite that.
Yes, I updated to 8.3.10, partly to see if it would solve this problem.
I'm not clear on how connection pooling would help this problem. I would have 100 lightweight backends, whether they were pooled or not, always sitting around. Or are you suggesting that I not use Apache::DBI to maintain persistent connections, and instead rely on the connection pooler to provide fast connect/disconnect from Postgres?
Thanks,
Craig
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
