Re: Kernel kills postgres process - help need

Hervé Piedvache escribió:
> Tom,
>
> Le mercredi 9 janvier 2008, Tom Lane a écrit :
> > =?utf-8?q?Herv=C3=A9_Piedvache?= <bill(dot)footcow(at)gmail(dot)com> writes:
> > > When I have a lot of connexions (persistante connexions from 6 web
> > > apache/php serveurs using PDO, about 110 process on each web servers) on
> > > the server, or long request, it's difficult for me to know when it's
> > > appening, the kernel seems to kill my postgresql process then the server
> > > become completly instable, and most of the time need a reboot ...

> > Have you considered using a connection pooler in front of a smaller
> > number of backends?
>
> You never answered me to this point ... we use persistants connections so I
> don't understand the interest of using a pooler ...

The problem with persistent connections is that they are, well,
persistent -- so they keep resources allocated, which the server cannot
then use for other things. The PHP model of persistent connections is
silly and useless, because each PHP process keeps an open connection (or
more than one, if it connects to different databases), which is then
idle most of the time.

A pooler also keeps the connections open, but they are given in turns to
different PHP processes as they need them. The total number of open
connections to the database server is lower, which leads to resource
wastage being lower.

> Otherwise, what pooler do you recommand, and what will be the improvement for
> us ?

The two most recommended ones I've seen around here are pgbouncer and
pgpool. I think pgbouncer is supposed to perform better, at the cost of
not having certain bells and whistles (which you may not need anyway).

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.