[CentOS] Where is cached memory going?

Tue Aug 19 16:42:47 UTC 2008
David Dyer-Bennet <dd-b at dd-b.net>

On Tue, August 19, 2008 11:31, ABBAS KHAN wrote:
> As by the time, I've learned that Linux works by caching apps by using a
> lot
> of RAM and then it reallocates the new stuff by cleaning the old cached
> pages from memory as compared to other OSs. With 2 gigs of RAM often I see
> the free memory only as 100-400MB. Using TOP or PS, it doesn't look like
> any
> program or process is using excessive memory (the highest process is seen
> with 1-2% total memory). *So, my questions are:*
>  what programs are using that much of memory? (or cached memory)

It's very likely being used as disk cache.  You can get some more numbers
by running top, and looking at the last two lines of the headers.  I
routinely see over 1GB of cache on a not very active 4GB system.  Your
meminfo output is the same numbers, and looks completely normal to me.

Free memory is *bad*; it means it's being wasted completely.  Memory used
for disk caching is instantly available if it's suddenly needed for a

> Is that really due to a lot of cache in the memory
> *if yes, then, is there a way to parse the cache to findout what
> applications are eating up the cache?*

It's only indirectly tied to an application; it's cached disk blocks.  You
could say the process that read that file last is responsible, but the
*next* process to read those blocks is the one that would benefit.

> *how to free the cached memory?*

Why do you want to?  As I said, "free" memory is memory that's going to
waste.  Unless you have severe real-time issues with a process becoming
runnable where the difference between discarding a clean cached page, and
just allocating a free page, will make a difference, there's no point.  If
you DO have that level really extreme real-time performance issues, you
need to understand the whole virtual memory system an order of magnitude
better than you seem to.  That's off in a far corner of the Linux
application space -- Linux can do some real-time stuff, but it's not the
first choice for hard real-time environments last time I talked to any of
those people.

David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info