Re: [GENERAL] Re: [HACKERS] postgres processes

On Mon, Jun 14, 1999 at 12:10:01PM +0200, Jan Wieck wrote:
> Karl DeBisschop wrote:
>
> > From: Remigiusz Sokolowski <rems(at)gdansk(dot)sprint(dot)pl>
> >
> > My problem is, that server is used not only as database server, but also
> > (and in general) as mail server - I think that tehre are some other
> > services too.
> > I've used persistent connections to database (and I think I now understand
> > why so big processor usage), so postgres processes haven't die after
> > serve requests but wait for another.
> > Hmm... I have one question more - every postgres process takes about 5% of
> > processor time ( I've used to measure top command ) - it is normal or may
> > be processor is too slow?
> >
> > We use a similar configuration, and initially had similar problems.
> > We just don't use persistent connections in php anymore, and things
> > work fine - In our case, the number of reconnects saved by pconnect
> > would be small anyway.
> >
> > Another strategy would be to start a second apache server on a
> > different port or different machine, use it only for redirects to the
> > pages that call postgres (assuming this is not your whole site). Then
> > throttle the second server back as described above (we haven't
> > actually done this - but it seems it should work).
>
> I don't know anything about the internals of php, but I have
> similar problems with an Apache module I'm (still) writing.
>
> Using Apache 1.3.3 I've tried to use persistent connections
> to a content server. The methods available for a module
> include a call AtExit, which is called just before the actual
> Apache server process will be terminated (due to Apache
> shutdown or because too many spare servers).

PHP3's module version uses the standard ap_register_cleanup()
call to register its shutdown function. This function calls then
all PHP module specific shutdown functions, so that PostgreSQL
persistent connection should be closed properly.

I don't know of any situation where Apache would not call these
registered handlers (I'm not familiar with the Apache
internals...). Additionally, I've been running a site for a
client for about two years now which uses PHP and persistent
connections to PostgreSQL heavily - I don't think we have ever
seen such problems as described previously.

>
> But there's nothing that tells about a timeout. In the case
> of a communication or scripting timeout, Apache does a
> longjmp() back into the mainloop and clears the pool. That's
> the reason why sockets, files and memory allocations under
> Apache should be done via the Apache pool utilities, and not
> using the low level functions (as in PostgreSQL with
> palloc()).
>
> It MIGHT be the case, that php has that problem when using
> persistent database connections and that after a timeout, an
> unclosed connection is hanging around causing another hanging
> PostgreSQL backend.
>
>
> Jan
>
> --
>
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me. #
> #========================================= wieck(at)debis(dot)com (Jan Wieck) #
>
>
>

--

Regards,

Sascha Schumann
Consultant