Re: Many postmasters...

Jean-Christophe Boggio wrote:
> Using Linux RH7.0 with correct gcc and glibc, PG7.03, Apache 1.3.14
> and PHP4. We have several unresolved questions :

> * Is it normal that
>   ps aux |grep postgres
>   shows (what we want : processes own by postgres) multiple postgres
>   backends (which seems normal to me) *AND* multiple postmaster (same
>   full cmd line).
>   Sometimes we also have "defunct" postgresses.

Yes, this would be normal.  Due to the fork nature of the backend, you
will see with ps, depending upon traffic, the actual postmaster fork
before the backend (postgres) is exec'd. I don't see that here due to my
use of a pooling webserver, but non-pooled situations will have backends
bouncing up and down constantly.  The defunct postgres processes are the
ones that are going away, but haven't yet been removed from the process
table, IIRC.

> * we start postgres with a /etc/rc.d/init.d script that launches
>   pg_ctl -w <many options here> start
>   When invoked from the shell, this command never returns to the shell
>   by itself, we have to press <enter>. This behaviour prevents the
>   script for terminating properly. Is there a way around this ?
>   Not tried echo | pg_ctl .... yet

The init.d script has an & after the pg_ctl line.  If it didn't return,
your system would never finish booting, due to the sequential nature of
the RedHat 7 SysV init setup.  Now, pg_ctl is kept running; it just
doesn't block the initscript.

> * every backend created by an Apache session opens many files (in our
>   case, about 80 including the indexes) and many backends will finally
>   generate an "Too many files open" message. We first increased the
>   /proc/sys/fs/file-max to 8192 but that's a lot !

>   The apache/php server always uses the same connect parameters for
>   every page but it seems php's pg_pconnect() behaves just like
>   pg_connect. Shouldn't we have apache hold a few backends connected ?

Thanks to the non-pooled connection scheme of Apache/PHP, the way the
persistent pconnect mechanism works is non-obvious.  Each apache
_process_ can hold a configured number of connections open -- but that
is then multiplied by the number of apache _processes_.

So, to run persistent connections in a usable manner on Apache/PHP
requires a huge number of backends, requiring an even larger number of
open files.  File-max at 8192 is probably middle of the road for such a
system.

Too bad PHP can't use AOLserver's pooled connections -- that would be a
big win. PHP can run on AOLserver -- it just doesn't yet use the pooled
API.

Apache 2.0's multithreaded nature will help this -- unless a mechanism
can be devised to share database connections amongst multiple full
processes for older Apache's.

Multithreading is a big win for clients that generate multiple
connections -- it's not a big win for backends that serve multiple
connections.  IMHO.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11