| 1 |
On Sunday 16 August 2009 20:56:59 Philip Webb wrote: |
| 2 |
> 090816 Raul Gonzales wrote: |
| 3 |
> > I have a 2G of physical RAM but even without any major activity |
| 4 |
> > output of free,vmstat and top reports only ~64M free. |
| 5 |
> > |
| 6 |
> > free -m |
| 7 |
> > total used free shared buffers cached |
| 8 |
> > Mem: 1953 1888 65 0 143 1557 |
| 9 |
> > -/+ buffers/cache: 187 1765 |
| 10 |
> > Swap: 2055 0 2055 |
| 11 |
> |
| 12 |
> The crucial figure is '187', which is what is usable. |
| 13 |
> You have a lot of something cached: any idea what it might be ? |
| 14 |
> -- the kernel should delete that stuff, if it needs the space. |
| 15 |
|
| 16 |
top, free and every other tool that examines /proc lies through it's teeth. |
| 17 |
|
| 18 |
Well, not really, but it's necessary to know what exactly it is measuring and |
| 19 |
also how the kernel is written. |
| 20 |
|
| 21 |
But first: Raul, there is nothing wrong with your box. It is working as |
| 22 |
designed. |
| 23 |
|
| 24 |
The "used" column literally means memory that in use for something, somewhere. |
| 25 |
The "free" column literally means memory that is not in use anywhere. It's |
| 26 |
normally around 2 or 3 % of total physical RAM. |
| 27 |
|
| 28 |
In Raul's case, the kernel has decided to allocate 1557M of RAM to cache. A |
| 29 |
particular block might have cached data in it, or it might not. It might have |
| 30 |
been used then marked as up for not in use anymore, or it might never have |
| 31 |
been written to since last reboot. It doesn't matter. All that does matter is |
| 32 |
that the kernel has decided that those blocks of memory *may* be used for |
| 33 |
caching. |
| 34 |
|
| 35 |
The trick is that if more memory is needed by apps than what is listed as |
| 36 |
immediately available and free, the kernel will search out chunks that it can |
| 37 |
de-allocate, then it will do so. |
| 38 |
|
| 39 |
Why does the kernel do this? It's a programming technique called lazy- |
| 40 |
deallocation (similar to lazy-initialization) and it's used because it is |
| 41 |
efficient. It means the kernel only has to do work when it needs to do work. |
| 42 |
De-allocating memory as soon as it is not in use is expensive and usually a |
| 43 |
waste of time - it's very likely that that very chunk of memory will almost |
| 44 |
immediately be used once again. If so, why bother de-allocating it at all? |
| 45 |
|
| 46 |
Bottom line: You, the user, do not really know what the kernel is doing with |
| 47 |
memory. It's also changing about 100 million times a second and your eyes |
| 48 |
don't work that fast. The kernel is designed to do these things in an |
| 49 |
autonomous fashion because it knows what to do, and you the user do not. The |
| 50 |
most you can do about this is provide hints as to how the kernel should |
| 51 |
operate and then let it get on with it. |
| 52 |
|
| 53 |
top, free, et all, simply show snapshots of memory state at a point in time. |
| 54 |
You should ignore the absolute values they display and concentrate more on how |
| 55 |
the numbers are changing over time. A value that gradually increases while no |
| 56 |
real processes are running would indicate a problem for example. |
| 57 |
|
| 58 |
This is all very correct and follows good engineering principles. |
| 59 |
|
| 60 |
-- |
| 61 |
alan dot mckinnon at gmail dot com |
Archives