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
Attachment:
pgpmMRAdUQGgk.pgp
Description: PGP signature
