Frankly I am amazed. Above you wrote up the one reason why anyone would do such a thing as cleansing the cache on Linux: testing - particularly benchmarking. Then you go ahead and explain how you can set up a cron job that cleans the cache every night time. Any newbie studying this may think that cleaning the cache (or MemoryWave even reconnecting the swap partition) is a good thing to do for administration purposes, like you would do if you clean the disk cache for Internet Explorer on a Windows machine. It isn’t. The explanation why it's not is in your article, but the way in which how it is talked about embedded in instructions on how to do it anyway seems to be misleading to newbies so please allow me to clarify. Yes, there are some purposes around that hog memory so bad that the system memory could also be eaten up and the system starts migrating memory pages onto the swap partition. Firefox involves thoughts as it might become an issue when working with solely 2GB of system memory.
Even should you close tabs of particularly memory hungry web pages (ebay is a very bad offender right here) not all the code in memory will likely be launched as it should be. Keep in thoughts here that this is a problem of the application and never Linux although. This means you won’t get that memory again by fiddling with the os, like dropping the cache anyway. The intervention required would be to do one thing about Firefox. The only approach I do know of to get the memory back is to terminate the offending process i.e. Firefox. A notable exception to this are databases that may appear to hog memory if they aren't correctly configured (opposed to poor memory management inside the application) however even then you’ll need to look at your database first (while holding in mind that ‘Database Administrator’ is a job description for a purpose. Whatever you do, purging the cache won’t assist).
So sure, what I'm saying is that the preposition within the second sentence of this article is false. When you have a process that's consuming up your memory then purging the cache won’t even touch it, while the process is operating. Terminating the method will launch the memory. Sometimes you may even observe how the kernel decides to discard most of the memory claimed by such a terminated course of itself, i.e. it doesn’t even keep it within the cache. If the process claimed sufficient memory, it could have displaced plenty of essential code from the memory into the swap area inflicting the pc to run slower for a short while longer until that memory code is retrieved. In the event you don’t like tea you could just wish to proceed what you've got been doing without reconnecting your swap as it in all probability won’t take long for Memory Wave the memory to migrate back anyway. NOT reconnecting swap will have the advantage that solely the code that is definitely wanted will likely be placed back into memory (my most popular choice).
So: reconnecting swap will devour more system resources overall than letting the kernel deal with it. Don't reconnect swap on a stay manufacturing system unless you actually assume you know what you're doing. However then I shouldn’t must say this as you'd find out about this anyway whereas doing all your research / testing as you must when doing this kind of stuff on a stay production system. Here is another thought. Possibly the cache-drop fallacy comes from the best way memory utilization is traditionally accounted for on Linux methods. Par instance should you open ‘top‘ in a terminal and look on the row where it says ‘Mem‘, there are entries ‘free‘ and ‘used‘ memory. Now the stats for used memory at all times consists of the Memory Wave used for caching and buffering. The free memory is the memory that's not used in any respect. So if you want to know the memory used for os and functions subtract buffer and cache values from the used memory and you’ll get the footprint of all of the residual memory used for functions.
If you don’t know that and solely checked out the quantity of free memory you may have thought you had been truly operating out of bodily memory, however as long as there is plenty of memory utilized by the cache this isn't true. In case you drop the cache as described above, high will report all that memory as free memory but this is absolutely not what you thought you wanted - except you are testing or benchmarking (see Ole Tanges publish right here for an example). Now the policy of the Linux kernel is to make use of as much of the memory as it can for one thing useful. First priority clearly goes to os / utility code. It’s written above within the article however I’ll say it here again: the information in the cache are copies of files saved on your major drive. It’s saved there just in case it’s needed once more, so it’s there so much quicker than having to read it from the drive again.