Re: what's making executables so large?
- From: Winston <wbe@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 12 Jul 2012 15:33:07 -0400
I originally asked:
2) What's making the virtual sizes so large? Is it caused by having
each shared library mapped to a separate memory page and memory page
size being "too large" (thus mostly empty) or some such?
John Levine <johnl@xxxxxxxx> kindly replied:
Somethinge like that. Many programs map in vast amounts of stuff that
they never touch in most program runs. Looking at "top", I see images
of chrome that are 784M, but only 80M in RAM.
to which I replied (in part):
I'm still curious what all that stuff is, though. Is it really
needed and useful? (and my original, erroneous VM formula)
bonomi@xxxxxxxxxxxxxxxxxxxx (Robert Bonomi) took a great deal of time
writing a detailed reply, ending with:
Now, aren't you sorry you asked? <*evil* grin>
Not at all. :)
Unfortunately, you've described virtual memory in general, whereas I'm
trying to figure out why the results on FreeBSD/amd64 in particular look
so different vs. other systems, such as Solaris 8/SPARC.
Thank you, though, because preparing this reply encouraged me to run
several more tests. :)
My original points of comparison were programs under Solaris/SPARC,
using Solaris tools to monitor process size and virtual memory. The
programs map in a similar set of .so libraries that have their own VM
requirements under both O/Ses.
Two programs that originally caught my attention were Emacs and an X11
program of mine. The RSS sizes under FreeBSD and Solaris were similar,
but the virtual sizes were hugely different.
On the Solaris machine I used, the virtual size of its Emacs is ~13 MB
and a core dump is of similar size (ls -l). Under FreeBSD, Emacs has a
comparable RSS size, but a ~170 MB virtual size and core dump size.
That's 13* larger! Yes, they're different versions; yes, Emacs loads
lots of stuff that could be different.
My X11 program #1 (Xt, Xaw) is a more controlled test. I compiled the
same exact program on both systems. As expected, it has a similar RSS
size on both, but the virtual size (and core dump size) is ~70MB under
FreeBSD and only ~4MB under Solaris, and I know my code isn't explicitly
asking for an extra 66 MB.
/usr/bin/vi's virtual size has a smaller multiple. It's 12+MB under
FreeBSD vs. ~3MB under Solaris; the RSS sizes are nearly identical.
My X11 program #2 (Xt, no widgets) under Solaris has SZ=4016; under
FreeBSD, VSZ=32612, while the RSS sizes reported by ps are nearly
identical.
OTOH, not all programs do this. My testing found that trivial programs
such as "main(){ sleep(600); }" and variations with "char buf[5000000];"
have about the same virtual size or smaller under FreeBSD. I thought
for a while that maybe it was just X11 programs, but there seem to be
counter-examples.
The way to answer this definitively will be get the tools that can show
me the process's page map to work on these processes, and see what's
what. (As noted elsewhere, the /proc info on my system gives results
for some processes, but not the ones I'm interested in.)
Thanks,
-WBE
.
- Follow-Ups:
- core dump option? (was Re: what's making executables so large?)
- From: Winston
- Re: what's making executables so large?
- From: Michel Talon
- Re: what's making executables so large?
- From: Robert Bonomi
- core dump option? (was Re: what's making executables so large?)
- Prev by Date: dhclient not detecting link down?
- Next by Date: Re: what's making executables so large?
- Previous by thread: dhclient not detecting link down?
- Next by thread: Re: what's making executables so large?
- Index(es):
Relevant Pages
|
