On Tue, Jan 16, 2007, Oded Arbel wrote about "Why are GNOME applications (and
applets) take so much [EMAIL PROTECTED] memory ?":
> And can something be done about it ??
I'll offer only partial explanations; I hope that someone else can offer
better exlanations, and/or a solution.
Of course, my own solution is simple: I don't use neither Gnome, nor KDE. I
hand-pick individual applications which I like. I picked a window manager
(called "ctwm"), an editor, clock, and so on, each separately based on their
own merits. And one of these merits were memory use (my home computer has just
256 MB of memory, so low memory use is very important for me).
> PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
> 2994 root 15 0 241M 40512 10032 S 2.0 1.1
> 2h23:59 /usr/bin/Xorg :0 -br -audit 0 -auth /var/gdm/:0.X
>
> X is here for reference - it takes up ~200 - 250MB of virtual and it has
> the excuse that it needs to be big.
Maybe you already know this, but let me just verify that we're on the same
page. "VIRT" is the amount of virtual memory that the process has mapped.
It isn't certain that all this memory is used, or ever been used - it is
possible that the program allocated some memory and never used it and it
doesn't take up space anywhere (I'll get back to this issue shortly). Even
stranger (but true), it is possible that this "virtual memory" isn't RAM at
all, but a mapping of a file (such as a shared library), or of something else.
In the X server case, it is very common for the server to map the graphic
card's memory, which often results in very high virtual memory figures for
the X server.
The "RES" figure is the amount of memory that the program now currently uses.
You can see that the X server actually uses much less memory than that VIRT
figure.
> lets look at the stuff that take
> about the same amount of virtual:
> 3170 odeda 18 0 204M 17932 6556 S 0.0 0.5 3:52.88 nautilus
> --sm-config-prefix /nautilus-wyDKQV/ --s
>
> Nautilus at idle - I don't have any file manager window open and I'm not
> copying or doing any file operation that requires nautilus - it just
> needs to draw the desktop when I have it exposed (which is not that
> often, I like to work with maximized windows and use a lot of
> workspaces). Still it takes almost as much virt as X does.
What can explain huge VIRT size and small RES figure at the same time?
I can offer several possibilities - I don't know which of these applies to
Nautilus (or your other examples):
1. Software which only knows how to grow, but not shrink.
Consider for example Firefox; At some stage in time, you had 10 tabs open,
each with very complex pages. Later, you close all the tabs but one, but
none of the free()ed memory is actually returned to the system. All this
unused memory wasted space in the swap, but doesn't waste RAM.
This sort of problem is very common for monolithic programs (which, unlike
the original Unix philosophy, don't run quickly and exit, and don't run
subprocesses).
2. Programs which uses a lot of threads.
Each thread has its own stack; In Linux, these stacks have fixed sized
(they don't grow dynamically like the heap) and needs to be allocated in
advance. Traditionally, each thread had a 8 MB stack, so if your program
had 10 threads, it would allocated 80 MB of virtual memory even without
doing a thing! This 80 MB would turn up on the "VIRT" number but would not
actually consume any resources (not RAM and not swap space).
If I remember correctly, the per-thread stack size was later reduced to 2 MB
which is more reasonable, but still can explain some of the VIRT size for
multi-threaded programs.
3. Programs which use a lot of shared libraries.
Shared libraries are great. They allow executables to be smaller, and less
memory to be used when a lot of applications are running. However, when a
program uses a shared library, it "maps" it into memory, and the shared
library size gets added to the VIRT number. Gnome and KDE applications use
tons of shared libraries, so even before they allocate a single byte,
a huge size is already added to their VIRT figure.
Note that while shared libraries increase the VIRT figure, they do not
actually consume resources (RAM or swap space), so they are not "bad".
Check out /proc/.../maps to see which shared libraries are mapped by
some process.
> 3310 odeda 16 0 181M 32696 4344 S 0.0 0.9
> 5:55.44 /usr/libexec/netspeed_applet2 --oaf-activate-iid=
>
> The network monitoring applet - shows a small box with the amount of
> bytes being passed through the interface at the moment. It also graphs
> network history for the last 5 minutes or so - still it uses 180MB,
What worries me here is not the 181M VIRT figure (which like I explained,
could mean nothing), but rather the 32 MB RES figure. This crappy applet
really takes up 32 MB of your real RAM. This is inexcusable. Just to compare,
here are some RES figures for a few programs I use:
xterm: 1-1.5 MB
zsh: 0.5-2 MB
ctwm: 1.5 MB
xload: 0.8 MB
xdaliclock: 0.8 MB
xemacs: 18 MB
firefox: 70 MB
As you can see, your lousy net speed applet takes up 40 times more memory (!)
then the clock and load applets I use. Even xemacs with dozens of buffers open
takes up half the memory of your applet. I'd throw this applet directly into
the garbage-can applet ;-)
O tempora, o mores :(
> almost 20% of my total dynamic memory. I cringe to think about what
> people with 512MB memory do.
Like I said, my home computer has 256 MB ;-)
And it actually works very well form me. When I don't try to run Eclipse
and OpenOffice at the same time, that is... (these two, and Firefox, are
the worst memory hogs that I use).
> Now before you go all "its only virtual, who cares", I'll have you know
> that my OS is set up with 2GB of swap for 1GB of dynamic memory, which I
Try the following experiment: sum up all the VIRT numbers you see. You'll
be surprised that you will (I think) get more than 3GB. Like I said, not all
the "virtual memory" listed in the VIRT figure actually consumes swap space.
> switching is a pain. If I want to add a serious IDE to the mix, I know
> I'm risking it. And every so often - about twice a week - I get a system
> that is so unresponsive due to swap thrashing (if I log in remotely I
> can see swap at 100% and kswapd taking up all the resources), that I
> have to kill X just to gain control over it.
In my opinion, Gnome and KDE almost turn your comptuer into... Windows...
I hope you realise you have an option to avoid them altogether. This is
what I love about Linux - options.
--
Nadav Har'El | Tuesday, Jan 16 2007, 26 Tevet 5767
[EMAIL PROTECTED] |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |If you drink, don't park; Accidents cause
http://nadav.harel.org.il |people.
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
