apache (httpd) on FC1/i386 vs FC2/x86_64: 3-8 times as much memory consumption?

[Axel Thimm]

On Fri, Sep 03, 2004 at 11:20:43AM +0100, Joe Orton wrote:
> On Thu, Sep 02, 2004 at 04:34:20PM -0400, Jakub Jelinek wrote:
> > On Thu, Sep 02, 2004 at 09:23:10PM +0100, Joe Orton wrote:
> > > I see the same thing here, not looked into it before though.
> > > 
> > > It's interesting, if you look at the mappings of the httpd process on
> > > x86_64, for each mmaped object there is an extra region mapped with
> > > PROT_NONE, which you don't see on i686.  I presume this is counted in
> > > the VmSize calculation - it adds up to about 100Mb of address space on
> > > the system I tested.
> > > 
> > > e.g.
> > > 
> > > 2a9b033000       12K r-xp /usr/lib64/libpanel.so.5.3
> > > 2a9b036000     1012K ---p /usr/lib64/libpanel.so.5.3
> > > 2a9b133000       16K rw-p /usr/lib64/libpanel.so.5.3
> > > 
> > > vs
> > > 
> > > 00d57000       12K r-xp /usr/lib/libpanel.so.5.3
> > > 00d5a000        4K rw-p /usr/lib/libpanel.so.5.3
> > > 
> > > is this libc behaviour by design? Jakub?
> > 
> > Well, not glibc, but binutils.
> > The thing is, x86-64 ELF has 1MB pagesize, while i386 ELF 4KB,
> > so the x86-64 binaries and shared libraries must be usable even when kernel
> > uses 1MB pagesize.
> > 
> > The gap in between RE and RW segment is there so that the library occupies
> > less memory (eats less 4KB pages).
> >
> > If something counts in PROT_NONE mappings into the process size, it should
> > be fixed.
> 
> Such mappings are certainly counted in the VmSize reported by
> /proc/pid/status, which looks like it (mm->total_vm) is used in the OOM
> killer heuristics and also in the 'ps' VSZ output.  I couldn't argue
> otherwise since it is vm space which is being "used".
> 
> But if these mappings are not really consuming memory, then they are not
> necessarily the cause of your problems, Axel.  It does mean that if you
> *do* run out of memory, then the httpd processes are more likely to get
> OOM killed on x86_64 than on i386.

Well, I can only argue phenomenologically, the same httpd config under
FC1/i386/1GB could easily serve the default 150 MaxClients. Migrating
to FC2/x86_64/1GB (e.g. same amount of RAM, but i386->x86_64 and
FC1->FC2) requires me to reduce MaxClients to below 50 to keep the
machine from running OOM.

The VM numbers are 8 times as big, and perhaps this figure is
irrelevant as discussed above, but the RSS size is also 3 times higher
than on the old server, and that is probably hurting (20MB RSS times
150 MaxClients is already at 3GB, while previously it was at 6MB times
resulting to 1.2GB).

How can I debug the memory consumption on this box? Which figures are
the ones to look for and which ones do accumulate for the OOM killer?
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20040903/ea3dc246/attachment-0002.bin