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 sharedbuffers cached
Mem: 823512026884845546636 0 815620 697696
-/+ buffers/cache:11751687059952
Swap: 2097136 02097136
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
