From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 09:49:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C101B1E2 for ; Wed, 31 Oct 2012 09:49:33 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 50F408FC16 for ; Wed, 31 Oct 2012 09:49:32 +0000 (UTC) Received: from MightyAtom.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id q9V9nVLN084995 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 31 Oct 2012 09:49:31 GMT Date: Wed, 31 Oct 2012 09:49:21 +0000 From: Karl Pielorz To: Konstantin Belousov , Alfred Perlstein Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Message-ID: In-Reply-To: <20121030175138.GA73505@kib.kiev.ua> References: <20121030182727.48f5e649@X220.ovitrap.com> <20121030194307.57e5c5a3@X220.ovitrap.com> <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> <20121030175138.GA73505@kib.kiev.ua> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 09:49:33 -0000 --On 30 October 2012 19:51 +0200 Konstantin Belousov 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. 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 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 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