1 |
Apparently, though unproven, at 16:45 on Saturday 18 September 2010, Florian |
2 |
Philipp did opine thusly: |
3 |
|
4 |
> Hi list! |
5 |
> |
6 |
> I have a bit of a problem. I'm on KDE-4.4.5 and it eats memory for |
7 |
> breakfast. Directly after booting, everything is okay but the usage |
8 |
> grows significantly. I wonder whether this is expected behavior. |
9 |
> |
10 |
> The following statistics have been taken after 8 days of uptime during |
11 |
> which the system was on standby most of the time during work days and at |
12 |
> night. |
13 |
> |
14 |
> free -m |
15 |
> total used free shared buffers cached |
16 |
> Mem: 3754 3588 165 0 57 258 |
17 |
> -/+ buffers/cache: 3271 482 |
18 |
> Swap: 6142 978 5163 |
19 |
> |
20 |
> A desktop machine that has 4GB RAM and still needs to swap?! |
21 |
> |
22 |
> Excerpt from top: |
23 |
> VIRT RES SHR S %CPU %MEM TIME+ COMMAND |
24 |
> 1094m 484m 10m S 0 12.9 96:43.01 firefox |
25 |
> 932m 471m 15m S 0 12.6 5:10.20 akregator |
26 |
> 384m 303m 2856 S 0 8.1 59:43.43 virtuoso-t |
27 |
> 709m 282m 2936 S 0 7.5 0:40.51 nepomukservices |
28 |
> 839m 146m 15m S 0 3.9 8:37.76 thunderbird-bin |
29 |
> 191m 131m 532 S 0 3.5 12:30.73 dbus-daemon |
30 |
> 902m 105m 5288 S 0 2.8 0:30.16 krunner |
31 |
> 263m 105m 1724 S 0 2.8 2:31.18 squid |
32 |
> 255m 61m 6672 S 7 1.6 305:04.24 X |
33 |
> 1106m 55m 7756 S 0 1.5 4:22.73 amarok |
34 |
> 534m 54m 10m S 0 1.5 2:33.94 kopete |
35 |
> 559m 52m 6536 S 0 1.4 56:52.37 nepomukservices |
36 |
> 718m 38m 12m S 4 1.0 143:36.62 plasma-desktop |
37 |
> 295m 33m 2048 S 0 0.9 1:59.32 mysqld |
38 |
> 360m 17m 1856 S 0 0.5 0:07.56 tomboy |
39 |
> 445m 16m 3392 S 0 0.4 38:54.36 nepomukservices |
40 |
> 365m 14m 6356 S 1 0.4 27:38.49 konsole |
41 |
> 438m 11m 4928 S 0 0.3 0:20.12 kded4 |
42 |
> 508m 11m 6364 S 0 0.3 0:45.79 kwin |
43 |
|
44 |
Like I posted in another thread today, the memory columns in top do not mean |
45 |
what most people think they mean, nor are they simplistic. |
46 |
|
47 |
The columns tell you the amount of memory that process can access. This is |
48 |
vitally important to understand. Modern memory managers in all OSes have the |
49 |
concept of shared code and shared memory. It would be insanely wasteful for |
50 |
each process to have it's own copy of all the data in RAM it ever uses. At a |
51 |
minimum, every process would need a full copy of glibc loaded into RAM. |
52 |
|
53 |
Here's what really happens (simplistic version): |
54 |
|
55 |
An app loads, and links to libraries it needs. They may or may not already be |
56 |
in RAM; if nor, they are loaded. Those binary images increase the amount of |
57 |
RAM the process may address. The app uses more RAM for it's own purposes (data |
58 |
it is using) and after a while lots of that data is still in RAM but no longer |
59 |
being used. |
60 |
|
61 |
When things get tight, the kernel has a good long hard look at memory usage |
62 |
and starts chucking bits away that can be dispensed with safely. How much |
63 |
control do you, the user, have over this: none whatsoever. Why: because the |
64 |
situation is changing millions of times a second and there's no way you can |
65 |
keep up. |
66 |
|
67 |
It's like your heart. You don't actually want to be bothered keeping the damn |
68 |
thing pumping consciously. So you let your brain stem do all that heavy |
69 |
lifting. With memory, the kernel is your brain stem. |
70 |
|
71 |
Your numbers above look perfectly normal. Most of that RAM can and will be |
72 |
dumped when something else comes along that needs it. The clincher is your |
73 |
swap usage. After 8 days you are using only about 12% of total which indicates |
74 |
the kernel is quite happily keeping everything under control and still has |
75 |
plenty of wiggle room left to keep you humming along nicely. |
76 |
|
77 |
The only point where this memory scheme goes wrong is when an app has a memory |
78 |
leak - it has finished with some data in RAM and does not release it. The |
79 |
chances that all your "memory hogs" all have leaks like this are very small. |
80 |
|
81 |
Final conclusion: you have nothing to worry about. |
82 |
|
83 |
|
84 |
|
85 |
|
86 |
> |
87 |
> Okay, I'm used to Firefox taking much memory. I'm okay with that since |
88 |
> it's the most heavily used application currently running. But why does |
89 |
> Akregator need that much memory? It doesn't even have any tabs open at |
90 |
> the moment and is just running minimized in the background. |
91 |
> |
92 |
> Virtuoso looks like an optional Soprano dependency which in turn is |
93 |
> needed for Nepomuk. Are the default use flags for dev-libs/soprano |
94 |
> suboptimal? What happens if I choose other flags for Soprano? |
95 |
> |
96 |
> The rest of the list is a bit suspicious, as well. Especially DBus and |
97 |
> Kopete look like they live way beyond their means (or my means ;) ). |
98 |
> |
99 |
> Do other users experience the same? |
100 |
> |
101 |
> Thanks in advance! |
102 |
> Florian Philipp |
103 |
|
104 |
-- |
105 |
alan dot mckinnon at gmail dot com |