Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 31 Oct 2012 16:06:30 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Karl Pielorz <kpielorz_lst@tdx.co.uk>
Cc:        freebsd-hackers@freebsd.org, Alfred Perlstein <bright@mu.org>
Subject:   Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?..
Message-ID:  <20121031140630.GE73505@kib.kiev.ua>
In-Reply-To: <C25F1D47C8D6BA6E3A072D4B@MightyAtom.tdx.co.uk>
References:  <A92CE63E6E6DB93B366F4A42@MightyAtom.tdx.co.uk> <20121030182727.48f5e649@X220.ovitrap.com> <E46B717DCFC9273E8BEC5100@MightyAtom.tdx.co.uk> <20121030194307.57e5c5a3@X220.ovitrap.com> <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> <20121030175138.GA73505@kib.kiev.ua> <C25F1D47C8D6BA6E3A072D4B@MightyAtom.tdx.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help

--6nSyB+bcl/pT7+kx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 31, 2012 at 09:49:21AM +0000, Karl Pielorz wrote:
>=20
> --On 30 October 2012 19:51 +0200 Konstantin Belousov <kostikbel@gmail.com=
>=20
> wrote:
>=20
> > I suggest to take a look at where the actual memory goes.
> >
> > Start with procstat -v.
>=20
> Ok, running that for the milter PID I get seem to be able to see smallish=
=20
> chunks used for things like 'libmilter.so', and 'libthr.so' / 'libc.so' -=
=20
> 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.

>=20
> 2010           0x400000           0x413000 r-x   19    0   1   0 CN-- vn=
=20
> /usr/local/sbin/milter
> 2010           0x613000           0x800000 rw-   15    0   1   0 ---- df
> 2010        0x800613000        0x80062b000 r-x   24    0  97   0 CN-- vn=
=20
> /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=
=20
> /usr/lib/libmilter.so.5
> 2010        0x800839000        0x800a38000 ---    0    0   1   0 ---- df
> 2010        0x800a38000        0x800a39000 rw-    1    0   1   0 C--- vn=
=20
> /usr/lib/libmilter.so.5
> 2010        0x800a39000        0x800a3c000 rw-    0    0   0   0 ---- --
>=20
> Then there's a bunch of 'large' blocks e.g..
>=20
>  PID              START                END PRT  RES PRES REF SHD  FL TP P=
ATH
> 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.

>=20
> Then lots of 'little' blocks,
>=20
> 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.

>=20
>=20
> The memory usage figures seem to have 'stabilized' now - SIZE/RES seem to=
=20
> track around 9 times the size of the 6.4 system, for a comparative load.
>=20
> We can probably live with this (as they have come back down overnight as=
=20
> load fell off) - i.e. they don't appear to be continuously growing (the=
=20
> binaries were heavily profiled under 6.x and found to have no internal=20
> leaks).
>=20
> -Karl

--6nSyB+bcl/pT7+kx
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iEYEARECAAYFAlCRMGYACgkQC3+MBN1Mb4hINACfQFyivGuLWOlvZARD8wWFpZVV
7ooAnjfFjvPOH0fMVy3RcIxxQ5dMHpoM
=uMXA
-----END PGP SIGNATURE-----

--6nSyB+bcl/pT7+kx--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121031140630.GE73505>