Re: [GENERAL] Re: [HACKERS] postgres processes - Mailing list pgsql-hackers

Karl DeBisschop wrote:

>    From: Remigiusz Sokolowski <rems@gdansk.sprint.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).

    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@debis.com (Jan Wieck) #