Thread: Lots of postmaster processes
In our installation of the postgres 7.4.7, we are seeing a lot of the following postmaster processes (around 50) being spawned by the initial postmaster process once in a while: postgres 3977 1 1 Nov03 ? 15:11:38 /s/postgresql-7.4.7/bin/postmaster -D /scratch.1/postgres/condor-db-7.4.7 ...... postgres 31985 3977 0 10:08 ? 00:00:00 /s/postgresql-7.4.7/bin/postmaster -D /scratch.1/postgres/condor-db-7.4.7 postgres 31986 3977 0 10:08 ? 00:00:00 /s/postgresql-7.4.7/bin/postmaster -D /scratch.1/postgres/condor-db-7.4.7 postgres 31987 3977 0 10:08 ? 00:00:00 /s/postgresql-7.4.7/bin/postmaster -D /scratch.1/postgres/condor-db-7.4.7 postgres 31988 3977 0 10:08 ? 00:00:00 /s/postgresql-7.4.7/bin/postmaster -D /scratch.1/postgres/condor-db-7.4.7 ...... At the same time when these processes being spawned, sometimes there is also the checkpoint subprocess. I am not sure if that is related. The document doesn't provide any information. The other activity going on at the same time is a 'COPY' statement from a client application. These extra processes put a considerable load on the machine and cause it to hang up. Thanks, Ameet
Ameet Kini <akini@cs.wisc.edu> writes:
> In our installation of the postgres 7.4.7, we are seeing a lot of the
> following postmaster processes (around 50) being spawned by the initial
> postmaster process once in a while:
Lots of postmaster processes can only come from lots of connection
requests. You need to look at the behavior of your client code and
see why it's doing that.
It might also be helpful to use a "ps" command that shows you the
per-process state displays rather than the original postmaster arguments.
What platform are you on? The only one I know of offhand that does
the latter by default is Solaris --- see FAQ_Solaris for how to work
around it.
regards, tom lane
We're running on tao linux. And yes, there are many client connection requests sent to the server at the same time. My impression was that client connection requests usually show up as a postgres process not postmaster but I could be wrong. Is it that the postmaster forks off a process on receiving a client connection request and then renames the process to postgres and I'm issuing my ps command while its in the intermediate state when its still called postmaster? Thanks, Ameet On Tue, 13 Dec 2005, Tom Lane wrote: > Ameet Kini <akini@cs.wisc.edu> writes: > > In our installation of the postgres 7.4.7, we are seeing a lot of the > > following postmaster processes (around 50) being spawned by the initial > > postmaster process once in a while: > > Lots of postmaster processes can only come from lots of connection > requests. You need to look at the behavior of your client code and > see why it's doing that. > > It might also be helpful to use a "ps" command that shows you the > per-process state displays rather than the original postmaster arguments. > What platform are you on? The only one I know of offhand that does > the latter by default is Solaris --- see FAQ_Solaris for how to work > around it. > > regards, tom lane > Ameet
Ameet Kini <akini@cs.wisc.edu> writes:
> We're running on tao linux. And yes, there are many client connection
> requests sent to the server at the same time. My impression was that
> client connection requests usually show up as a postgres process not
> postmaster but I could be wrong. Is it that the postmaster forks off a
> process on receiving a client connection request and then renames the
> process to postgres and I'm issuing my ps command while its in the
> intermediate state when its still called postmaster?
A bit hard to believe, unless there's something delaying the
subprocesses from reaching their first set_ps_display() call.
Offhand it looks like DNS problems could cause that (especially if
you've got log_hostname enabled), or broken client code that doesn't
send the whole startup packet immediately.
However, a backend that's hung up that early in the startup process
really shouldn't be consuming noticeable resources, so I'm not sure why
this would create a performance issue for you.
regards, tom lane