On Wed, Oct 31, 2012 at 09:49:21AM +0000, Karl Pielorz wrote: > > --On 30 October 2012 19:51 +0200 Konstantin Belousov <[email protected]> > wrote: > > > I suggest to take a look at where the actual memory goes. > > > > Start with procstat -v. > > Ok, running that for the milter PID I get seem to be able to see smallish > chunks used for things like 'libmilter.so', and 'libthr.so' / 'libc.so' - > e.g. Since you neglected to provide the verbatim output of procstat, nothing conclusive can be said. Obviously, you can make an investigation on your own.
> > 2010 0x400000 0x413000 r-x 19 0 1 0 CN-- vn > /usr/local/sbin/milter > 2010 0x613000 0x800000 rw- 15 0 1 0 ---- df > 2010 0x800613000 0x80062b000 r-x 24 0 97 0 CN-- vn > /libexec/ld-elf.so.1 > 2010 0x80062b000 0x800634000 rw- 9 0 1 0 ---- df > 2010 0x800634000 0x80065f000 rw- 33 0 1 0 ---- df > 2010 0x80082b000 0x80082d000 rw- 2 0 1 0 ---- df > 2010 0x80082d000 0x800839000 r-x 12 12 2 1 CN-- vn > /usr/lib/libmilter.so.5 > 2010 0x800839000 0x800a38000 --- 0 0 1 0 ---- df > 2010 0x800a38000 0x800a39000 rw- 1 0 1 0 C--- vn > /usr/lib/libmilter.so.5 > 2010 0x800a39000 0x800a3c000 rw- 0 0 0 0 ---- -- > > Then there's a bunch of 'large' blocks e.g.. > > PID START END PRT RES PRES REF SHD FL TP PATH > 2010 0x801c00000 0x802800000 rw- 2869 0 4 0 ---- df > 2010 0x802800000 0x803400000 rw- 1880 0 1 0 ---- df > 2010 0x803400000 0x803800000 rw- 920 0 1 0 ---- df > 2010 0x803800000 0x804000000 rw- 865 0 1 0 ---- df > 2010 0x804000000 0x804400000 rw- 1024 0 4 0 ---- df > 2010 0x804400000 0x804c00000 rw- 627 0 1 0 ---- df > 2010 0x804c00000 0x805000000 rw- 1021 0 4 0 ---- df Most likely, these are malloc arenas. > > Then lots of 'little' blocks, > > 2010 0x7ffff0161000 0x7ffff0181000 rw- 16 0 1 0 ---D df > 2010 0x7ffff0362000 0x7ffff0382000 rw- 16 0 1 0 ---D df > 2010 0x7ffff0563000 0x7ffff0583000 rw- 16 0 1 0 ---D df > 2010 0x7ffff0764000 0x7ffff0784000 rw- 16 0 1 0 ---D df > 2010 0x7ffff0965000 0x7ffff0985000 rw- 16 0 1 0 ---D df > 2010 0x7ffff0b66000 0x7ffff0b86000 rw- 16 0 1 0 ---D df > 2010 0x7ffff0d67000 0x7ffff0d87000 rw- 16 0 1 0 ---D df > 2010 0x7ffff0f68000 0x7ffff0f88000 rw- 16 0 1 0 ---D df > 2010 0x7ffff1169000 0x7ffff1189000 rw- 16 0 1 0 ---D df And those are thread stacks. > > > The memory usage figures seem to have 'stabilized' now - SIZE/RES seem to > track around 9 times the size of the 6.4 system, for a comparative load. > > We can probably live with this (as they have come back down overnight as > load fell off) - i.e. they don't appear to be continuously growing (the > binaries were heavily profiled under 6.x and found to have no internal > leaks). > > -Karl
pgpM3vONjl8vE.pgp
Description: PGP signature
