Date: Mon, 22 Jan 2001 03:55:03 -0600 (CST) From: Mike Meyer <mwm@mired.org> To: Cliff Sarginson <cliff@raggedclown.net> Cc: Mike Meyer <mwm@mired.org>, Gustavo Vieira Goncalves Coelho Rios <gustavo@ifour.com.br>, questions@FreeBSD.ORG Subject: Re: small program eats lot of memory Message-ID: <14956.887.341176.486366@guru.mired.org> In-Reply-To: <E14KcyG-000IZe-00@post.mail.nl.demon.net> References: <E14KcyG-000IZe-00@post.mail.nl.demon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Cliff Sarginson <cliff@raggedclown.net> types:
> > Cliff Sarginson <cliff@raggedclown.net> types:
> > > On Sunday 21 January 2001 16:48, Mike Meyer wrote:
> > > > Gustavo Vieira Goncalves Coelho Rios <gustavo@ifour.com.br> types:
> > > > > I compiled and executed a small program and it's eating about 336
> > > > > of real memory (rss) and 840 of virtual size memory (vsz), may some
> > > > > one explain why a simple program eats about 1 MB of memory?
> > > > You linked it shared, right? That 1MB includes all of every shared
> > > > library it uses, whether it uses those functions or not.
> > > Pardon ! It certainly does not ! That is the point of shared libraries -
> > > the code is *shared* between processes using it. The required code is
> > > then made dynamically available.
> >
> > Shared libraries are mapped into the memory space of the process. As
> > such, they are part of the memory of the process, and should be
> > counted when adding up the memory of the process, so it'll be the rss
> > (if it's resident) and vsz of the process.
> >
> > Whether or not the physical memory is shared is another question, and
> > I'll let you all continue to debate that. I will say that, given the
> > price of disks, if the memory isn't shared, a system with static
> > binaries might be a better choice than one with dynamic binaries.
>
> So what does the word shared in shared memory mean then :)
> Hard to see what the point is if all processes load their own copy
> of shared memory libraries at run time..
> I think you will find that physically speaking there is only one libc...
> in memory under the shared model.
Since you replied to me, and I didn't have an opinion about shared
libraries being shared on memory or just disk, I'm assuming you're
claiming that my analysis of the way libc is used and the memory
counted.
Checking usage is easy: just truss a binary that uses shared libc, and
look for it in the output. Here's what I find:
access("/usr/lib/libc.so.3",0) = 0 (0x0)
open("/usr/lib/libc.so.3",0,027757775424) = 3 (0x3)
fstat(3,0xbfbffae4) = 0 (0x0)
read(0x3,0xbfbfeab4,0x1000) = 4096 (0x1000)
mmap(0x0,643072,0x5,0x2,3,0x0) = 672337920 (0x28131000)
mmap(0x281b5000,20480,0x3,0x12,3,0x83000) = 672878592 (0x281b5000)
mmap(0x281ba000,81920,0x3,0x1012,-1,0x0) = 672899072 (0x281ba000)
close(3) = 0 (0x0)
I.e. - it gets opened and mmap'ed into memory exactly like I
said. After it's mapped in, a second area is allocated r/w instead of
r/x, and a second r/w area is allocated from swap. They are all part
of the memory used by the process, and show up in the appropriate
sizes.
<mike
--
Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14956.887.341176.486366>