On Mon, 2005-02-14 at 18:45 -0500, Stas Bekman wrote:
that approach is not very practical if change your code base constantly. Since you will have to retune things every time you change your code.
I know, it's terrible, but it's all I've come up with so far. Maybe we need to rethink how the size-limiting modules work so that they can use something like the total amount of free physical RAM instead. I think that's sort of what you were thinking of too.
I'd rather see the kernel providing a new feature which tells us the exact amount of memory used by a group of forked processes (swapped in and out).
Me too, but I'm not holding my breath. We can find out how much total memory is free though, at least on Linux.
That particular information is far from being useful, since there is the cache. On my (linux) machine I have 0MB of free memory and 400-500MB of cached buffers. So on linux one needs to combine the two to get the answer. (see the output of free(1) on linux to see what I'm talking about)
So what you are saying is that whatever the technique is to get that remaining free memory, if we have it we could just set a limit on how much "free" memory is available and start killing Apache procs, when that limit is passed. I think that might just work. The roughest approach will be to just kill the current process. The fine tuned one will be to maintain a table of proc sizes as I've suggested before.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
