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 по дате отправления: