Greg Ames <[EMAIL PROTECTED]> writes:
> At ApacheCon in Orlando and in Santa Clara, I tried to attend as many
> pitches given by webmaster/admin/ISP type folks as possible, so I could
> learn a little about how our stuff is used in the real world. One theme
> I heard over and over was that heavyweight web workloads (database,
> mod_perl) should be isolated from lightweight workloads in order to
> minimize the memory footprint. Makes a lot of sense to me.
>
> But in order to have our problem here, a prerequisite is that
> heavyweight and lightweight requests are being served by the same
> process. hmmmm...seems like a sharp sysadmin would start by separating
> the long running stuff onto a different server instance or some such,
> and therefore would be much less likely to hit this situation.
This is a completely different sort of heavyweight. mod_perl is big
in memory... A long download has no special memory requirements. The
sysadmin won't have a reason to segregate things.
> AFAIK, Paul hit this problem because of idle_server_maintenance and/or
> MaxRequestsPerChild - true? If that's really the extent of it, I
> believe there's a pretty easy solution. If idle_server_maintenance
> triggers this, it is thrashing (i.e., first trying to cut back on the
> number of processes, then trying to increase them, then trying to cut
> back again while the first process with the mixed weight workloads is
> still hanging around). So duh!, let's make it stop thrashing. All we
> have to do is limit the number of processes that can be terminated by
> idle_server_maintenance to one at a time. Piece of cake.
>
> If you buy that, then why doesn't that solution work for
> MaxRequestsPerChild as well? Think about it. That number is basically
> for memory leak tolerance on a buggy server. How important is it that
> we always stop a process precisely when we hit that number? not very,
> IMO. For the low end folks it's probably the default anyway, which we
> developers just pulled out of the air. So if we have our mixed workload
> process basket case scenario going on, just hold off on killing any more
> processes until the first one terminates completely.
more caffeine/study of perform_idle_server_maintenance needed on my part
sounds reasonable from 10,000 feet...
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
