Received: by taz.hyperreal.com (8.6.12/8.6.5) id GAA14878; Thu, 14 Sep 1995 06:55:38 -0700 Received: from life.ai.mit.edu by taz.hyperreal.com (8.6.12/8.6.5) with SMTP id GAA14872; Thu, 14 Sep 1995 06:55:34 -0700 Received: from volterra.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) for new-httpd@hyperreal.com id AA01538; Thu, 14 Sep 95 09:55:28 EDT From: rst@ai.mit.edu (Robert S. Thau) Received: by volterra.ai.mit.edu (8.6.12/AI-4.10) id JAA04099; Thu, 14 Sep 1995 09:55:26 -0400 Date: Thu, 14 Sep 1995 09:55:26 -0400 Message-Id: <199509141355.JAA04099@volterra.ai.mit.edu> To: new-httpd@hyperreal.com Subject: Re: things to look for in runaway server? Sender: owner-new-httpd@apache.org Precedence: bulk Reply-To: new-httpd@apache.org Hmmm... at the times when it runs away, the nameserver stops reliably serving up hostnames. If, at the same time, it is *also* taking longer to produce no answer, then that would explain the runaway forking and the delays seen by clients (each server that accepts a connection waits several seconds for the name server --- since connections are coming in at about the same rate as normal, that means dramatically more requests are "in process" at any given time, corresponding to the increase in service time, which in turn accounts for the excess forking). This is, at best, an educated guess, but there is a way to test it (though it's not free of potentially noxious side effects) --- if I'm right, then\ compiling the server with -DMINIMAL_DNS will eliminate the delays and fork bombs... rst