Freeing RAM used by Linux for cache/buffers

Using applications, configuring, problems
Post Reply
Message
Author
mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

Freeing RAM used by Linux for cache/buffers

#1 Post by mcewanw »

I picked up the following useful tip in a post by user curaga on the tiny core forum:

First, at the commandline, try running the utility "free" and note the results. (You might want to use "sync" first as BruceB suggests later, though it works without that as it happens).

Now enter the following command and afterwords run "free" again:

Code: Select all

echo 3 > /proc/sys/vm/drop_caches
Eat your heart out Microsoft...



System seems to be just as responsive so perhaps it would be good to do this automatically at boot time?

It would certainly be excellent propaganda for new users who first run "free" to see how much memory their system is using immediately after booting. The results give me a lot of "comfort" on my old 256 MB RAM machine anyway, and it seems that I don't start filling up swap quite as quickly.

In fact there doesn't seem to be any major problem running the above command every now and then when using, for example, Seamonkey or Firefox web browser (though I imagine it will have some temporary effect on system responsiveness in terms of the benefits of cache - not that I'm qualitatively noticing anything negative).
Last edited by mcewanw on Sat 28 Dec 2013, 00:35, edited 2 times in total.

Bruce B

#2 Post by Bruce B »

It is supposed to sync first, example:

Code: Select all

sync && echo 3 > /proc/sys/vm/drop_caches

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

Freeing RAM used by Linux for cache/buffers - use of sync

#3 Post by mcewanw »

Bruce B wrote:It is supposed to sync first, example:

Code: Select all

sync && echo 3 > /proc/sys/vm/drop_caches
Yes, though the action is "non-destructive" it only drops clean caches so you should indeed do a sync first (also helps avoid possible problems with locking mechanisms).

From http://linux.die.net/man/5/proc:
/proc/sys/vm/drop_caches (since Linux 2.6.16)
Writing to this file causes the kernel to drop clean caches, dentries and inodes from memory, causing that memory to become free.

To free pagecache, use echo 1 > /proc/sys/vm/drop_caches; to free dentries and inodes, use echo 2 > /proc/sys/vm/drop_caches; to free pagecache, dentries and inodes, use echo 3 > /proc/sys/vm/drop_caches.

Because this is a non-destructive operation and dirty objects are not freeable, the user should run sync(8) first.
Note that in practice the kernel should free cache anyway when applications require more RAM, however the likelihood of that happening depends on how your system is tuned up in terms of "swappiness" (i.e. a characteristic which effects when the vm manager decides to swap out pages of RAM; the "swappiness factor" can be adjusted, but I prefer to stick with the default system "swappiness" settings since they have presumably been tested as reasonably optimal for a typical system configuration).

From http://kerneltrap.org/node/3000
a run-time tunable is available through the proc interface for anyone needing to adapt kernel behavior to their own requirements. To tune, simply echo a value from 0 to 100 onto /proc/sys/vm/swappiness. The higher a number set here, the more the system will swap.
It's a compromise of free RAM versus latency (responsiveness).

In practice, I find that the kernel tends to allow my swap space to fill up (i.e. part of virtual memory) such that my lo-RAM system can slow to a crawl. Freeing RAM manually, as above, alleviates the problem.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#4 Post by mikeb »

Interesting post .. cheers
In practice, I find that the kernel tends to allow my swap space to fill up (i.e. part of virtual memory) such that my lo-RAM system can slow to a crawl. Freeing RAM manually, as above, alleviates the problem.
I notice a magic 73MB of swap used .. certain apps seem to trigger it as sometimes it remains empty..never spent time tracing the pattern.

mike

edit...actually running this does dramatically drop free readings but in htop and xfce memory monitor very minor and I find the latter 2 more representitive.
Also puppy's free is the busybox one I believe whereas the full version gives a more complete picture....anyway memory management comes under the heading of devine mysteries where buffer, cache and used are all one :D

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

sys info "reports" versus actual RAM used

#5 Post by mcewanw »

mikeb wrote: edit...actually running this does dramatically drop free readings but in htop and xfce memory monitor very minor and I find the latter 2 more representitive.
Also puppy's free is the busybox one I believe whereas the full version gives a more complete picture....anyway memory management comes under the heading of devine mysteries where buffer, cache and used are all one :D
It is important not to confuse the reports output by the various measuring tools with the actual RAM used. htop and xfce mem manager makes a stab at reporting what "would be" the used/free RAM "if" buffers/cache was not being allocated (i.e. what they report is not the free RAM but an arithmetic calculation: RAM usage - buffer/cache usage). The utility "free" on the other hand (either version) makes an attempt to tell you the actual usage (including buffer/cache use). Gnu free has more options than free, but both are limited. All these tools you mention obtain their values from the /proc filesystem; an alternative is just to enter:

Code: Select all

cat /proc/meminfo
The command I gave in the top post (+ sync as described by BruceB) actually DOES clear the RAM as described. htop will not notice the difference because its "calculated" report will be much as before but the RAM itself actually has been flushed as "free" suggests.

If you are interested in more accurately measure RAM usage you would be better to use a tool such as "exmap" http://www.berthels.co.uk/exmap/doc.html which is described along with further information about "free" and so on in the following two article links:

http://ktown.kde.org/~seli/memory/analysis.html
http://www.ibm.com/developerworks/linux ... emory.html

As the ktown article says:
Various files in the /proc filesystem can provide information about memory. However they're are poorly documented (linux/Documentation/filesystems/proc.txt) and many of them are broken (and since top and free get their values the same way, they are equally broken). In /proc/PID/ there are several files:

* status - human-readable data about the process, includes some data shown by top
* stat/statm - similar, not in human-readable format
* maps - lists memory mappings of the process . . .
* smaps - lists memory mappings of the process with more details . . .
Note that there is also a utility called vmstat (+ more options than busybox versions of ps, top, w, kill, free, slabtop, and skill) which is available if you have procps installed on your system http://procps.sourceforge.net/
http://www.murga-linux.com/puppy/viewtopic.php?p=275329
http://www.murga-linux.com/puppy/viewtopic.php?p=306327
http://www.murga-linux.com/puppy/viewtopic.php?p=84431

You will notice from the ibm 'developerworks' article that exmap is able to accurately report the memory usage of individual processes and applications, which "free", for example, cannot.

However, as far as I remember exmap needs to be specially compiled for the kernel you are using since it involves a loadable kernel module. It has been compiled and tested on Ubuntu systems, though, so there may be a binary download available which will work with Upup at least.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#6 Post by mikeb »

Thanks for the explanation and further info...plenty to chew on, and certainly buffer/cache clearance is dramatic.
Just one related question...puppy tends towards the use of a swap file intead of the more usual partition...are there any significant differences in performance/usage?
regards

mike

User avatar
Argolance
Posts: 3767
Joined: Sun 06 Jan 2008, 22:57
Location: PORT-BRILLET (Mayenne - France)
Contact:

#7 Post by Argolance »

Bonjour,
:arrow: CleanRAM 0.1 (for test)

Cordialement.

Post Reply