Am 19.09.2010 10:25, schrieb Alan McKinnon: [...] > 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. >
I disagree on that last point. While it might be true that some of the statistics are not correct, I have a feeling that it is not acceptable or normal that a simple desktop system is not able to free enough memory to have more that 1/8 of it available for cache. I mean, my old system had 2 GB RAM and an equivalent Gnome system on it. It needed swap as well due to Firefox and Eclipse eating memory. But otherwise its usage was far less than what I see here.
