On Wed, 20 Mar 2002, Stas Bekman wrote: > mod_perl child processes save a lot of memory when they can share memory > with the parent process and quite often we get reports from people that > they lose that shared memory when the system decides to page out the > parent's memory pages because they are LRU (least recently used, the > algorithm used by many memory managers).
I'm fairly certain that this is not an issue. If a page was shared COW before being paged out, I expect it will be shared COW when paged back in, at least for any modern OS. [To verify that I wasn't talking through my hat, here, I just verified this using RedHat 7.2 running kernel 2.4.9-21. If you're interested in my methodology, drop me an email.] > I believe that this applies to all httpd modules and httpd itself, the > more we can share the less memory resources are needed, and usually it > leads to a better performance. I'm absolutely _certain_ that unmodified pages from executable files will be backed by the executable, and will thus be shared by default. > Therefore my question is there any reason for not using mlockall(2) in > the parent process on systems that support it and when the parent httpd > is started as root (mlock* works only within root owned processes). I don't think mlockall is appropriate for something with the heft of mod_perl. Why are the pages being swapped out in the first place? Presumably there's a valid reason. Doing mlockall on your mod_perl would result in restricting the memory available to the rest of the system. Whatever is causing mod_perl to page out would then start thrashing. Worse, since mlockall will lock down mod_perl pages indiscriminately, the resulting thrashing will probably be even worse than what they're seeing right now. Later, scott
