1 |
Am 19.09.2010 10:25, schrieb Alan McKinnon: |
2 |
[...] |
3 |
> Like I posted in another thread today, the memory columns in top do not mean |
4 |
> what most people think they mean, nor are they simplistic. |
5 |
> |
6 |
> The columns tell you the amount of memory that process can access. This is |
7 |
> vitally important to understand. Modern memory managers in all OSes have the |
8 |
> concept of shared code and shared memory. It would be insanely wasteful for |
9 |
> each process to have it's own copy of all the data in RAM it ever uses. At a |
10 |
> minimum, every process would need a full copy of glibc loaded into RAM. |
11 |
> |
12 |
> Here's what really happens (simplistic version): |
13 |
> |
14 |
> An app loads, and links to libraries it needs. They may or may not already be |
15 |
> in RAM; if nor, they are loaded. Those binary images increase the amount of |
16 |
> RAM the process may address. The app uses more RAM for it's own purposes (data |
17 |
> it is using) and after a while lots of that data is still in RAM but no longer |
18 |
> being used. |
19 |
> |
20 |
> When things get tight, the kernel has a good long hard look at memory usage |
21 |
> and starts chucking bits away that can be dispensed with safely. How much |
22 |
> control do you, the user, have over this: none whatsoever. Why: because the |
23 |
> situation is changing millions of times a second and there's no way you can |
24 |
> keep up. |
25 |
> |
26 |
> It's like your heart. You don't actually want to be bothered keeping the damn |
27 |
> thing pumping consciously. So you let your brain stem do all that heavy |
28 |
> lifting. With memory, the kernel is your brain stem. |
29 |
> |
30 |
> Your numbers above look perfectly normal. Most of that RAM can and will be |
31 |
> dumped when something else comes along that needs it. The clincher is your |
32 |
> swap usage. After 8 days you are using only about 12% of total which indicates |
33 |
> the kernel is quite happily keeping everything under control and still has |
34 |
> plenty of wiggle room left to keep you humming along nicely. |
35 |
> |
36 |
> The only point where this memory scheme goes wrong is when an app has a memory |
37 |
> leak - it has finished with some data in RAM and does not release it. The |
38 |
> chances that all your "memory hogs" all have leaks like this are very small. |
39 |
> |
40 |
> Final conclusion: you have nothing to worry about. |
41 |
> |
42 |
|
43 |
I disagree on that last point. While it might be true that some of the |
44 |
statistics are not correct, I have a feeling that it is not acceptable |
45 |
or normal that a simple desktop system is not able to free enough memory |
46 |
to have more that 1/8 of it available for cache. |
47 |
|
48 |
I mean, my old system had 2 GB RAM and an equivalent Gnome system on it. |
49 |
It needed swap as well due to Firefox and Eclipse eating memory. But |
50 |
otherwise its usage was far less than what I see here. |