My original question was asking why 42 "virtual host" httpd servers would
bring a system to its knees (Alphastation 255 4/233 64MB RAM) with 21
processes to each process pool. The answer was simple enough that too
many processes was causing excessive swapping and throwing the load
averages out of the roof. Anyway, over the course of refining our httpd
policies, I've compiled the following list of things to do to fix your
httpd server's performance. Please feel free to add on to this list to
either myself and I will post a summary of addendums or however else you
feel like posting performance hints.
If anyone feels like starting an FAQ for httpd performance, I would be
glad to offer this summary to its author ;)
1. Run apache!
- Apache supports a single process pool for multiple host ip addresses
this means that processes are used in the most efficient manner and
no resources are overallocated for the task of accepting http queries
2. Fix maxusers and maxuprc
- We were seeing errors attributed to these parameters while running
Netscape server and we changed these from their default to 256 each.
We changed them in the kernel config and recompiled but you could
also change them with sysconfigdb
- I dont know if this is necessary with apache but I assume it couldn't
hurt and depending on how many processes are run with apache under a
single user, you will probably encounter an error like:
vmunix: fork/procdup: task_create failed. Code: 0x11
while means you need to make these changes
3. Fix somaxconn
- Not until 4.0 does the default value for somaxconn set to 1024
- This parameter tells the kernel the upper limit on the listen
backlog queue which is used to stack multiple incoming requests
that arrive before an accept() call is issued.
- netstat -n | grep SYN_RCVD will give you an idea of the number of
queue'd connections.
- This problem will manifest itself if you start getting timeouts
connecting (very simply, if you connect to the port and you never
receive an accept or a connection refused (I dont know the TCP
translation, maybe you aren't received the ACK or
something...unimportant anyway))
- Values could be set from any numbers you feel like, however remember,
that not until 4.0 is the default set to 1024 so manybe 3.2, etc. does
not account for such high values
- Remeber that after changing this kernel parameter, the application that
makes use of this should also specify an appropriate backlog (the
second argument to the listen() system call). Also, you will need to
restart the application to make the new kernel value to affect.
- This can be fixed by patching the kernel with dbx:
# dbx -k /vmunix /dev/mem
dbx version 3.11.10
Type 'help' for help.
stopped at [thread_block:2046 ,0xfffffc00002a7298] Source not available
warning: Files compiled -g3: parameter values probably wrong
(dbx) assign somaxconn=128
128
(dbx) patch somaxconn=128
128
(dbx)
- BRad
Received on Sun May 26 1996 - 18:22:32 NZST