httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Hess <>
Subject Re: performance: using mlock(2) on httpd parent process
Date Wed, 20 Mar 2002 17:10:40 GMT
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

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.


View raw message