Shanti Subramanyam - PAE wrote: > I thought we were already checking for CMT installation and enabling > the kernel crypto ? At least it was there in Cool Stack. If you're > adding that, we should automatically also bump up the ServerLimit and > MaxClients for CMT. There's no plan to check the machine characteristics at install time.
Automatically setting large values of MaxClients for prefork seems problematic. Let's say the user of a production config file, after enabling the features they need for their workload, has an initial httpd vsize of 10MB (not unreasonable -- the default config file leads to a vsize of 60+MB and the slim feature set common to most configs has a vsize of perhaps 6MB). MaxClients=2048 * 10MB = 20GB of swap space just for Apache; if the machine doesn't have that much available just for Apache then its a potential denial of service. Various applications, including Apache, will start failing once swap space is exhausted. This is without worrying about actual steady-state heap use in the children, and just considering the configuration data and shared libraries and such inherited from the parent. The worker MPM uses a fraction of that amount of swap space use (at least if vsize is dominated by inherited shared libraries and configuration data), so it isn't such a big concern. I think users with large workloads need to understand MaxClients and memory use for different configs (including worker vs. prefork), and with that knowledge in hand, and being ready to test and observe, make a change. Alternatively they can bump it up in moderate increments and assess how Apache is handling load and using resources. As I mentioned in my sketch of the type of documentation which would be helpful: among other things: make sure you drive Apache to MaxClients during testing and survive