Re: [gentoo-user] KDE ridiculous memory usage

[Alan McKinnon <alan.mckinnon@gmail.com>]

Apparently, though unproven, at 16:45 on Saturday 18 September 2010, Florian 
Philipp did opine thusly:

> Hi list!
> 
> I have a bit of a problem. I'm on KDE-4.4.5 and it eats memory for
> breakfast. Directly after booting, everything is okay but the usage
> grows significantly. I wonder whether this is expected behavior.
> 
> The following statistics have been taken after 8 days of uptime during
> which the system was on standby most of the time during work days and at
> night.
> 
> free -m
>              total  used  free  shared  buffers  cached
> Mem:          3754  3588   165       0       57     258
> -/+ buffers/cache:  3271   482
> Swap:         6142   978  5163
> 
> A desktop machine that has 4GB RAM and still needs to swap?!
> 
> Excerpt from top:
>  VIRT  RES  SHR S %CPU %MEM     TIME+ COMMAND
> 1094m 484m  10m S    0 12.9  96:43.01 firefox
>  932m 471m  15m S    0 12.6   5:10.20 akregator
>  384m 303m 2856 S    0  8.1  59:43.43 virtuoso-t
>  709m 282m 2936 S    0  7.5   0:40.51 nepomukservices
>  839m 146m  15m S    0  3.9   8:37.76 thunderbird-bin
>  191m 131m  532 S    0  3.5  12:30.73 dbus-daemon
>  902m 105m 5288 S    0  2.8   0:30.16 krunner
>  263m 105m 1724 S    0  2.8   2:31.18 squid
>  255m  61m 6672 S    7  1.6 305:04.24 X
> 1106m  55m 7756 S    0  1.5   4:22.73 amarok
>  534m  54m  10m S    0  1.5   2:33.94 kopete
>  559m  52m 6536 S    0  1.4  56:52.37 nepomukservices
>  718m  38m  12m S    4  1.0 143:36.62 plasma-desktop
>  295m  33m 2048 S    0  0.9   1:59.32 mysqld
>  360m  17m 1856 S    0  0.5   0:07.56 tomboy
>  445m  16m 3392 S    0  0.4  38:54.36 nepomukservices
>  365m  14m 6356 S    1  0.4  27:38.49 konsole
>  438m  11m 4928 S    0  0.3   0:20.12 kded4
>  508m  11m 6364 S    0  0.3   0:45.79 kwin

Like I posted in another thread today, the memory columns in top do not mean 
what most people think they mean, nor are they simplistic.

The columns tell you the amount of memory that process can access. This is 
vitally important to understand. Modern memory managers in all OSes have the 
concept of shared code and shared memory. It would be insanely wasteful for 
each process to have it's own copy of all the data in RAM it ever uses. At a 
minimum, every process would need a full copy of glibc loaded into RAM.

Here's what really happens (simplistic version):

An app loads, and links to libraries it needs. They may or may not already be 
in RAM; if nor, they are loaded. Those binary images increase the amount of 
RAM the process may address. The app uses more RAM for it's own purposes (data 
it is using) and after a while lots of that data is still in RAM but no longer 
being used.

When things get tight, the kernel has a good long hard look at memory usage 
and starts chucking bits away that can be dispensed with safely. How much 
control do you, the user, have over this: none whatsoever. Why: because the 
situation is changing millions of times a second and there's no way you can 
keep up.

It's like your heart. You don't actually want to be bothered keeping the damn 
thing pumping consciously. So you let your brain stem do all that heavy 
lifting. With memory, the kernel is your brain stem.

Your numbers above look perfectly normal. Most of that RAM can and will be 
dumped when something else comes along that needs it. The clincher is your 
swap usage. After 8 days you are using only about 12% of total which indicates 
the kernel is quite happily keeping everything under control and still has 
plenty of wiggle room left to keep you humming along nicely.

The only point where this memory scheme goes wrong is when an app has a memory 
leak - it has finished with some data in RAM and does not release it. The 
chances that all your "memory hogs" all have leaks like this are very small. 

Final conclusion: you have nothing to worry about.




> 
> Okay, I'm used to Firefox taking much memory. I'm okay with that since
> it's the most heavily used application currently running. But why does
> Akregator need that much memory? It doesn't even have any tabs open at
> the moment and is just running minimized in the background.
> 
> Virtuoso looks like an optional Soprano dependency which in turn is
> needed for Nepomuk. Are the default use flags for dev-libs/soprano
> suboptimal? What happens if I choose other flags for Soprano?
> 
> The rest of the list is a bit suspicious, as well. Especially DBus and
> Kopete look like they live way beyond their means (or my means ;) ).
> 
> Do other users experience the same?
> 
> Thanks in advance!
> Florian Philipp

-- 
alan dot mckinnon at gmail dot com