In short: that's normal, and shouldn't cause your machine to be slow - unless it's starved of RAM, in which case the solution is to get more RAM, not to cache less.
Here's some sample output from my machine right now: poll...@andromeda:~$ free total used free shared buffers cached Mem: 8235120 2688484 5546636 0 815620 697696 -/+ buffers/cache: 1175168 7059952 Swap: 2097136 0 2097136 The values reported under "buffers" and "cached" represent files read from or written to disk, which the kernel is cached in RAM in case they're needed again soon. If you take the buffers and cached values from the first row and subtract them from the used value (or add them to the free value), you get the values on the second row, which are (usually) the more important figures. You haven't mentioned swap though - is your machine eating into swap? My machine isn't - hence the 0 in the used column on the third row. If your machine is chewing into swap, the slowness could be caused by the machine having to constantly swap things in and out of RAM. There's a slight chance you could fix this by tweaking the swappiness of your kernel - but more likely, you'll swap one kind of slowdown (applications swapping in/out) for another kind (commonly-used files having to be read from disk every time, rather than being cached in fast memory) The classic example of this is a memory-limited desktop machine running both GIMP and Firefox. Dumping buffers/cache means that both Gimp and Firefox run sluggishly, but you can swap between apps at will. Swapping out applications makes GIMP run faster while you're using it - but causes the whole system to freeze for a second when you swap to Firefox, and then freeze again when you swap back. http://kerneltrap.org/node/3000 has a lengthy discussion about the swappiness parameters (from the linux-kernel mailing list, back in 2004). In short, /proc/sys/vm/swappiness controls how much the kernel swaps - 0 means the kernel will avoid swapping at all costs and dump cached files instead; 100 means the kernel will swap out anything it can in favour of lots of caching. The best solution though is to get more RAM. It's cheap, and it makes everything faster. That is, assuming this is actually your problem.... (if this email is incoherent, it's because my morning coffee has had time to perk me up, but not enough time for me to actually be awake yet) On Fri, Feb 20, 2009 at 8:48 AM, Kyle <k...@attitia.com> wrote: > > Hi Slugger's > > It appears I need a lesson in Linux and memory management. > > If you could treat this request as if coming from a complete numpty please, > and simply explain the differences between Cached, Buffered and Application > Memory as they pertain to Linux? > > According to KDE SysGuard, my CentOS 5.2 server appears to "cache" its entire > 2GB quotient of physical RAM. And my general experience of the box > (implemented as file server, mail server, firewall and router) is that it is > slow. > > Something tells me it shouldn't be behaving like this? > -- > ------------------------------------------------------------------------ > Kind Regards > > Kyle > -- > SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ > Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html