This is actually wrong. For some reason (probably because of the way it's implemented internally) Linux includes shared memory allocations in the "cached" figure. If you calculate the amount of free memory using "free -m" in the way this web page advises, you'll think that memory is free when it really isn't - unlike true cache, shared memory cannot be discarded when the space is needed for something else.<p>I've actually had buggy desktop applications use several gigabytes of RAM as shared memory, so this can make a big difference.
How bizarre. In the 1993-94 time frame, one of the big talking points about Windows NT was that it was the only OS with an integrated file system cache. That wasn't true even at that time, as Solaris also had such a cache, but such is the nature of propaganda.<p>I'm tickled that what once was a big "technical" advantage becomes a major source of confusion. Presumably, OSes of Windows NT heritage have retained file system caching, which offers a huge performance benefit. Why don't Windows users have confusion over this issue? Doesn't Windows offer an easy way to check or is the whole thing presented clearly, or is Windows so complicated not many people get this far?<p>I'll also draw a parallel to DUI - without a breath-o-meter, DUI is a lot like driving while distracted. It's impossible to quantify, and therefore not that much of a crime. With a breath-o-meter, or with "top", it's possible to put a number on drunkeness or lack of free memory, and the whole thing becomes a problem.
A quick practical answer is to use htop and look at the memory bar.<p>* Green = resident memory used (probably what you want most of the time)<p>* Blue = buffers<p>* Yellow = cache
The page seems to be down.<p>Here's how it looked: <a href="http://web.archive.org/web/20131011053519/http://www.linuxatemyram.com/" rel="nofollow">http://web.archive.org/web/20131011053519/http://www.linuxat...</a>
This is the worst piece of Linux advice ever. I use Linux for many years and every time I had a memory leak or a process using too much memory, every google search about the problem would lead to some "guru" giving this advice.<p>This explanation which has been replicated thousands of times on every linux forum on the planet, prevents people from solving real problems. It started as a useful piece of information but nowadays it is spam.
Wow, I can't believe how many times I've had to explain this to people as they log on to shared VNC servers. "I thought this had 16G of RAM free, I asked for a 16G machine!". "It does, stop trying to read top!"<p>Now I'll just point them to this website.
I hate the invention of "burstable" RAM on VPSes for this reason. Eventually your IO cache grows until it has most of your guaranteed RAM. Now every new process is playing a game of Russian roulette with your hypervisor to see if it can actually allocate into your "burstable" RAM what the kernel is reporting is freely available.
<a href="https://www.kernel.org/doc/Documentation/sysctl/vm.txt" rel="nofollow">https://www.kernel.org/doc/Documentation/sysctl/vm.txt</a><p>You can drop cache by sending a byte into drop_cache.
that's funny, like avery complex or "smart" algorithm, if it works it's cool, but when something doesn't work, it makes it very hard to pinpoint a culprit.<p>I'm more and more inclined to either use stupider algorithm that at least I can explain to the user, incremental stuff where they can check intermediate results or taking into account the fact that this algorithm has to be conveyed to users in one way or another since inception.<p>I guess in this case a measure of the swap activity would be a good indicator that the current limiting factor is the RAM, but it also has to be credible. Somehow having 16G written on the box of the ram and 7G written in the "available ram" of a software makes everything more credible that saying "I have a pressure of 1.5madeupunit on the ram front". Human factors, again.
Another thing, you know how sometimes a USB stick needs some time to un-mount? This non-sync'ed data (say, a copy of a big file) eventually has to be written to the physical disk, and through the little pipe, takes time. Find out how much of this "dirty" buffer you have yet to physically write to the device, while giving the kernel 'hints' to sync the dirty blocks quickly, with:<p><pre><code> while true; do sync && grep Dirty /proc/meminfo; done
</code></pre>
Lots of gold to be mined from /proc/meminfo .. bonus points for wiring it up to gnuplot so you can get a real picture of the dynamics of the Linux kernel .. ! :)
Best way to check how much ram is actually free is to use a higher level tool like a task manager (from various DEs) or a command line tool like htop, they report the actual memory usage of processes
Not strictly accurate, in the "Why would you want to do this" regard.<p>Ages ago I was hacking linux onto an ARM soc that claimed to have memory it didn't (it wasn't aware of the display's DMA segment). It was near the top of the address space, so generally speaking it didn't cause too many problems, but until I could debug it I needed to keep memory usage low, wchih meant disabling the disk cache. What a shitshow that was :/
I always run Ganglia on my servers. You can see memory used, memory shared, memory cached, memory buffered, and memory swapped all over time as well as total in-core memory. This has saved me (and my team) from ever having to misinterpret command line output. Takeaway, Linux is smart about using memory, probably smarter than you. <a href="http://ganglia.sourceforge.net/" rel="nofollow">http://ganglia.sourceforge.net/</a>
I think it's still disinformative. Disk cache also uses RAM which is allocted and reserved by applications, of course data is swapped out in this situation. o you'll need more swap, but it isn't a bad thing at all. Even OS/2 did this a long time ago, nothing new at all.
So basically this is the inverse of swap. Using memory to make disk reads/writes faster, instead of using disk to make more memory.<p>If Linux is consistently doing this, why would you still need a swap partition?
Ehm. But sometimes stupid linux kernel prefers moving something usefull to swap and caching some shit instead of keeping stuff in ram and not doing caching.<p>So linux sometimes eats your RAM (but in different way).