Re: [GENERAL] Re: [HACKERS] postgres processes
От | Sascha Schumann |
---|---|
Тема | Re: [GENERAL] Re: [HACKERS] postgres processes |
Дата | |
Msg-id | 19990614130531.A1786@schumann.2ns.de обсуждение исходный текст |
Ответ на | Re: [GENERAL] Re: [HACKERS] postgres processes (wieck@debis.com (Jan Wieck)) |
Список | pgsql-hackers |
On Mon, Jun 14, 1999 at 12:10:01PM +0200, Jan Wieck wrote: > 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). 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@debis.com (Jan Wieck) # > > > -- Regards, Sascha Schumann Consultant
В списке pgsql-hackers по дате отправления: