Re: Freeing Connections

Поиск
Список
Период
Сортировка
От Ross J. Reedstrom
Тема Re: Freeing Connections
Дата
Msg-id 20011018221531.A15435@rice.edu
обсуждение исходный текст
Ответ на Re: Freeing Connections  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-admin
On Thu, Oct 18, 2001 at 01:55:33PM -0400, Tom Lane wrote:
> Andrew Hill <list@fornax.net> writes:
> > Normally, 32 connections is heaps for what I need. However, I often get
> > connections that seem to be doing nothing. For example:
>
> > [bash]
> >   \_ postmaster -i -D/var/pgsql/data -N 32 -B 64
> >   \_ [postmaster]
> >   \_ /var/pgsql/bin/postgres 202.174.32.67 postgres anb idle
> >   \_ /var/pgsql/bin/postgres 202.174.32.68 postgres anb idle
> >   \_ [postmaster]
> >   \_ /var/pgsql/bin/postgres 203.34.190.137 postgres bmf idle
> >   \_ [postmaster]
> >   \_ [postmaster]
> >   \_ [postmaster]
> >   \_ [postmaster]
> >   \_ /var/pgsql/bin/postgres 202.174.32.8 radius bmf idle
>
> Curious.  Can you attach to some of the unidentified processes with
> a debugger, and get a stack traceback from 'em?  Offhand I can't
> think of a reason for 7.0 to have any subprocesses that haven't
> changed their PS display.  It would help to know what they are doing.

Andrew doesn't mention his platform, but if it's linux, those could just
be swapped out processes: since the execution state gets swapped, the
kernel only has minimal info about the process, including the original
name. I'm guessing that his PHP setup is configured for persistent
connections with MAX_CON >32 and isn't reusing connections properly.
ISTR some vesion of PHP with exactly that bug. Should be in the mailing
list archives.

Ross

В списке pgsql-admin по дате отправления:

Предыдущее
От: Brian McCane
Дата:
Сообщение: Re: Please help - tks
Следующее
От: Andrew Hill
Дата:
Сообщение: Re: Freeing Connections