Re: Connection pooling for a mixture of lightweight and heavyweight jobs?
От | Craig James |
---|---|
Тема | Re: Connection pooling for a mixture of lightweight and heavyweight jobs? |
Дата | |
Msg-id | 4C5310C4.1040906@emolecules.com обсуждение исходный текст |
Ответ на | Re: Connection pooling for a mixture of lightweight and heavyweight jobs? ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Connection pooling for a mixture of lightweight
and heavyweight jobs?
|
Список | pgsql-admin |
On 7/30/10 10:37 AM, Kevin Grittner wrote: > Craig James<craig_james@emolecules.com> 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 werepooled 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
В списке pgsql-admin по дате отправления: