httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: Apache 0.7: too many processes
Date Mon, 26 Jun 1995 20:27:51 GMT
   Date: Mon, 26 Jun 95 15:29 BST
   From: drtr@ast.cam.ac.uk (David Robinson)
   Precedence: bulk
   Reply-To: new-httpd@hyperreal.com

   This would be a pretty major disincentive for a low-use site to run apache.
   Running tens of daemons is very wasteful on swap space and kernel resources,
   and will put off sys admins.

Is that so?  As you note immediately after saying this:

   But a 0.7 server with a small number of daemons
   (5, say) would probably provide an inferior service to a 0.6 server.
   All it would take is one netscape user to access a page with a few inline
   images, and your site is saturated.

In other words, under peak conditions you *need* to be able to run
tens of daemons simultaneously or performance will be terrible.
What's more, since peaks may arise without warning, you need those
swap space and kernel resources to be available to the web server all
the time, even if there isn't an actual process pre-forked and serving
as a placeholder.

(In any case, the amount of resources actually consumed by having the
pre-forked children around is not that great; my process pool
currently averages about 300K/process for 20, or about 6 megabytes
total (printout below) --- that's not much these days for a dedicated
server.  NB this is Shambhala, but I don't think whatever difference
there is between it and 0.7.x is enough to make a major impact).

BTW, I do think there's an issue which can reasonably be addressed
here, which is trying to find the right value for StartServers
adaptively, rather than making the webmaster guess.  However, as the
experience at Cardiff suggests, I think the main issue here is making
sure that you have enough of them that they don't all get tied up
talking to slow clients.  At any rate, any strategy for adaptively
adjusting child server lifetimes should probably keep that in mind, as
well as the connection arrival rate...

rst

PS: as promised, here's ps alx output for my server pool (these
processes have all been running since 3:00 AM, so I don't expect them
to get much bigger than this):

       F UID   PID  PPID CP PRI NI  SZ  RSS WCHAN    STAT TT  TIME COMMAND
80488000   0  3623     1  6   5  0 104    0 child    IW   ?   0:00 ./shambhala 
  488001   8  5092  3623  0   1  0 360  496 socket   S    ?   2:55 ./shambhala 
  488001   8  5093  3623  1   1  0 276  400 socket   S    ?   3:10 ./shambhala 
  488000   8  5094  3623  0   1  0 324    0 socket   IW   ?   3:33 ./shambhala 
  488001   8  5095  3623  0   1  0 276  424 socket   S    ?   3:10 ./shambhala 
  488000   8  5096  3623  0   1  0 312    0 socket   IW   ?   2:48 ./shambhala 
  488001   8  5097  3623  2   1  0 300  468 socket   S    ?   3:13 ./shambhala 
  488001   8  5098  3623  0   1  0 312  464 socket   S    ?   2:47 ./shambhala 
  488001   8  5099  3623  1   1  0 324  476 socket   S    ?   3:01 ./shambhala 
  488000   8  5100  3623  0   1  0 336    0 socket   IW   ?   3:13 ./shambhala 
  488000   8  5101  3623  0   1  0 324    0 socket   IW   ?   2:40 ./shambhala 
  488001   8  5102  3623  0   1  0 276  468 socket   S    ?   3:03 ./shambhala 
  488001   8  5103  3623  4   1  0 312  488 socket   S    ?   3:01 ./shambhala 
  488001   8  5104  3623  1   1  0 352  488 socket   S    ?   3:00 ./shambhala 
  488001   8  5105  3623  0   1  0 308   76 socket   S    ?   3:13 ./shambhala 
  488000   8  5106  3623  1   1  0 300    0 socket   IW   ?   3:12 ./shambhala 
  488001   8  5107  3623  1   1  0 312  484 socket   S    ?   2:43 ./shambhala 
  488001   8  5108  3623  1   1  0 300  472 socket   S    ?   2:43 ./shambhala 
  488001   8  5109  3623  0   1  0 324  456 socket   S    ?   3:01 ./shambhala 
  488001   8  5110  3623  0   1  0 344  484 socket   S    ?   3:12 ./shambhala 
  488001   8  5111  3623  2   1  0 276  448 socket   S    ?   2:56 ./shambhala 

Mime
View raw message