On Oct 27, 2008, at 12:38 PM, FreeBSD wrote:
You need to keep your MaxClients setting limited to what your
system can run under high load; generally the amount of system
memory is the governing factor. [1] If you set your MaxClients
higher than that, your system will start swapping under the load
and once you start hitting VM, it's game over: your throughput will
plummet and clients will start getting lots of broken connections,
just as you describe.
According to top, we have about 2G of Inactive RAM with 1,5G Active
(4G total RAM with amd64). Swapping is not a problem in this case.
With 4GB of RAM, you're less likely to run into issues, but the most
relevant numbers would be the Swap: line in top under high load, or
the output of "vmstat 1" / "vmstat -s".
It would also be helpful to know what your httpd's are looking like in
terms of size, and what your content is like. For Apache serving
mostly static content and not including mod_perl, mod_php, etc, you
tend to have 5-10MB processes and much of that is shared, so you might
well be able to run 400+ httpd children. On the other hand, as soon
as you pull in the dynamic language modules like perl or PHP, you end
up with much larger process sizes (20 - 40 MB) and much more of their
memory usage is per-process rather than shared, so even with 4GB you
probably won't be able to run more than 100-150 children before
swapping.
After checking multiple things (MySQL, networks, CPU, RAM) when a
drop occurs, we determined that everytimes there is drop, the number
is Apache's process is MaxClients (ps aux | grep httpd | wc -l) and
the new http request doesn't get answer from Apache (the TCP
hanshakes completes but Apache never push the data).
Yes, that aspect is going to be the same pretty much no matter what
the bottleneck is or how large you set MaxClients to. You will end up
with significantly better results (fewer drops, higher aggregate
throughput) if you tune appropriately than if you try to ramp
MaxClients up further than the available hardware can support.
You might find that checking out the URLs being most commonly listed
in http://yourdomain.com/server-status when you run into high load
problems will point towards a particular script or dynamic content
which is causing a bottleneck.
Regards,
--
-Chuck
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
