Thread: zombie postmasters
Hello to all, In a web environment, a user can repeatedly starts and abort large queries which create a large number of zombie postmasters. Is there a way to control the postmaster zombies so that they don't clog up the system resources. thanks, hamid Hamid Khoshnevis emarQ.com 1488-1188 W. Georgia St. Vancouver, BC V6E 4A2, Canada Ph: (604) 687-7111 Fx: (604) 687-7222 http://www.emarq.com hamid@emarq.com
Not a direct answer, but... I think zombies (under most, if not all unices) don't use resources, other than the PID. - chad On Tue, Nov 16, 1999 at 03:06:35PM -0800, Hamid Khoshnevis wrote: > Hello to all, > In a web environment, a user can repeatedly starts and abort large queries > which create a large number of zombie postmasters. Is there a way to > control the postmaster zombies so that they don't clog up the system > resources. > > thanks, > > hamid > > Hamid Khoshnevis > emarQ.com > 1488-1188 W. Georgia St. > Vancouver, BC V6E 4A2, Canada > Ph: (604) 687-7111 > Fx: (604) 687-7222 > http://www.emarq.com > hamid@emarq.com > > > ************ >
You can place timeouts on the queries and terminate the query if it takes too long. Troy > > Hello to all, > In a web environment, a user can repeatedly starts and abort large queries > which create a large number of zombie postmasters. Is there a way to > control the postmaster zombies so that they don't clog up the system > resources. > > thanks, > > hamid > > Hamid Khoshnevis > emarQ.com > 1488-1188 W. Georgia St. > Vancouver, BC V6E 4A2, Canada > Ph: (604) 687-7111 > Fx: (604) 687-7222 > http://www.emarq.com > hamid@emarq.com > > > ************ > >
Hamid Khoshnevis wrote: > In a web environment, a user can repeatedly starts and abort large queries > which create a large number of zombie postmasters. Is there a way to > control the postmaster zombies so that they don't clog up the system > resources. I am assuming that by "web environment" you are speaking of utilizing a PostgreSQL database via a CGI, Servlet, etc... If this is the case it is usually easiest to make sure that your program gracefully handles a client disconnect by cleanly disconnecting from the database. This usually involves a little more code, and strict error checking on the part of your web application, but it will reduce headaches in the long run. Depending on the programming environment you are using you may be able to employ a technique such as connection pooling/handling to seperate the actual database access from the program handling IO. This way even if the client disconnects in the middle of a large query the connection manager can still cleanly disconnect from the database or clean up from the offending statement.. Utilizing a connection handler offers other benefits as well; namely it can eliminate the need to open a new database connection for every CGI process or Servlet thread. This can reduce overhead by making it unneccesary for Postgres to start a new process for yet another client, and hence authenticating another user. ~Stephen == Stephen J Lombardo Web/Database Application Developer Montclair State University ==
On Tue, Nov 16, 1999 at 06:39:27PM -0500, Stephen J Lombardo allegedly wrote: > Depending on the programming environment you are using you may be able to > employ a > technique such as connection pooling/handling to seperate the actual database > access from the program > handling IO. This way even if the client disconnects in the middle of a large > query the > connection manager can still cleanly disconnect from the database or clean up > from the offending statement.. > > Utilizing a connection handler offers other benefits as well; namely it can > eliminate the need to open > a new database connection for every CGI process or Servlet thread. This can > reduce overhead by > making it unneccesary for Postgres to start a new process for yet another > client, and hence authenticating > another user. Where can I find such a connection handler? Or would I be better of writing one myself? I need to access PostgreSQL from a custombuild scriptinglanguage running under a threaded webserver, so I can't use libpq straight out of the box. Such a connection handler might be the answer to my problem. Mathijs
"Hamid Khoshnevis" <hamid@emarq.com> writes:
> In a web environment, a user can repeatedly starts and abort large queries
> which create a large number of zombie postmasters.
It shouldn't be possible for there to be zombie postgres processes ---
the postmaster process should reap dead backends more or less instantly.
Either your postmaster is getting wedged somehow, or there is a
configure/install problem that has broken the postmaster's handling
of child-process exit. What platform are you using, exactly? What
if anything shows up in the postmaster log when this happens?
regards, tom lane
>
> "Hamid Khoshnevis" <hamid@emarq.com> writes:
> > In a web environment, a user can repeatedly starts and abort large queries
> > which create a large number of zombie postmasters.
>
> It shouldn't be possible for there to be zombie postgres processes ---
> the postmaster process should reap dead backends more or less instantly.
> Either your postmaster is getting wedged somehow, or there is a
> configure/install problem that has broken the postmaster's handling
> of child-process exit. What platform are you using, exactly? What
> if anything shows up in the postmaster log when this happens?
No, Tom.
It confused me too first. But with Zombie, he didn't meant
what you and me think a Zombie is. And it aren't postmaster
ones, it are regular backends that still run a huge query
where the client is already gone.
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) #
> "Hamid Khoshnevis" <hamid@emarq.com> writes:
> > In a web environment, a user can repeatedly starts and abort large queries
> > which create a large number of zombie postmasters.
The first question is whether you mean real "zombies" (as indicated by ps)
or a bunch more process than you expected ("process leak"). I've seen the
latter a number of times and it generally indicates failure to properly
close connections in your application. I find the same techniques used for
debuging file descriptor leaks work for finding these problems.
-Z-