There are always many friends who have doubts about the memory management of Linux. The previous article on the memory management method under Linux does not seem to clear everyone's doubts. In the new version of the core, it seems to provide a new solution to this problem, and it is specially transferred for your reference. Finally, I also attach my opinion on this method, and you are welcome to discuss it together.
When files are frequently accessed under Linux, the physical memory will be used up quickly. When the program ends, the memory will not be released normally, but will always be used as a cache. This question seems to be asked by many people, but they have not seen any good solution. So let me talk about this.
1. The usual situation
Let's talk about the free command first:
# free -m total used free shared buffers cached Mem: 249 163 86 0 10 94 -/+ buffers/cache: 58 191 Swap: 511 0 511
in:
total total memory
used used memory
free free memory
shared total memory shared by multiple processes
buffers Buffer Cache and cached Page Cache size of disk cache
- buffers/cache (used) memory: used - buffers - cached
+buffers/cache (available) memory: free + buffers + cached
available memory=free memory+buffers+cached
With this foundation, we can know that my current used is 163MB, free is 86MB, buffer and cached are 10MB and 94MB respectively.
So let's see what happens to the memory if I do a copy file.
# cp -r /etc ~/test/ # free -m total used free shared buffers cached Mem: 249 244 4 0 8 174 -/+ buffers/cache: 62 187 Swap: 511 0 511
After the execution of my command, the used is 244MB, the free is 4MB, the buffers is 8MB, and the cached is 174MB. God, they were all eaten by cached. Don't worry, this is a practice to improve the efficiency of file reading.
In order to improve the efficiency of disk access, Linux has made some careful designs. In addition to caching dentry (for VFS, to speed up the conversion of file path names to inodes), it also adopts two main Cache methods: Buffer Cache and Page Cache. The former is for reading and writing of disk blocks, and the latter is for reading and writing of file inodes. These caches effectively shorten the time of I/O system calls (such as read, write, getdents).
Then someone said that for a while, linux will automatically release the memory used. After waiting for a while, we use free to try again to see if there is a release?
# free -m total used free shared buffers cached Mem: 249 244 5 0 8 174 -/+ buffers/cache: 61 188 Swap: 511 0 511
Nothing seems to have changed. (In fact, memory management is also related to Swap) So can I release these memory manually? The answer is yes!
2. Manually release the cache
/proc is a virtual file system, and we can read and write to it as a means of communicating with the kernel entity. That is to say, the behavior of the current kernel can be adjusted by modifying the files in /proc. Then we can free the memory by adjusting /proc/sys/vm/drop_caches. The operation is as follows:
# cat /proc/sys/vm/drop_caches 0
First, the value of /proc/sys/vm/drop_caches, which defaults to 0.
# sync
Execute the sync command manually (Description: The sync command runs the sync subroutine. If the system must be stopped, run the sync command to ensure the integrity of the file system. The sync command writes all unwritten system buffers to disk, including modified i-nodes, deferred block I/O, and read and write mapped files)
# echo 3 > /proc/sys/vm/drop_caches # cat /proc/sys/vm/drop_caches 3
Set /proc/sys/vm/drop_caches value to 3
# free -m total used free shared buffers cached Mem: 249 66 182 0 0 11 -/+ buffers/cache: 55 194 Swap: 511 0 511
Run the free command again, and you will find that the current used is 66MB, the free is 182MB, the buffers is 0MB, and the cached is 11MB. Then the buffer and cache are effectively released.
The usage of /proc/sys/vm/drop_caches is explained below
/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 first
3. My opinion
The above article gives a more "intuitive" answer to the long-term questions of many users about Linux memory management, which I think is a bit like a compromise by the core development team. I have reservations about whether to use this value, or mention it to users.
As can be seen from man, this value is only provided from the core version after 2.6.16, that is, the old version of the operating system, such as Hongqi DC 5.0, and versions before RHEL 4.x are not available; if the system memory is enough Observation, I still intend to look at the usage rate of swap and the size of the two values of si/so;
the common question of users is, why is free so small, and whether the memory is not released after closing the application? But in fact, we all know that this is because Linux's memory management is different from that of Windows. Small free does not mean that the memory is not enough. You should look at the last value of the second line of free: -/+ buffers/cache: 58 191, which is the amount of memory available to the system.
The actual project tells us that if the application has problems such as memory leaks and overflows, it can be judged quickly from the usage of swap, but it is more difficult to view the free. On the contrary, if at this time, we tell the user to modify a value of the system and "can" release the memory, the free will be large. What will users think? Don't you think the OS "has a problem"? So, I think since the core can quickly clear the buffer or cache, it is not difficult to do (this is obvious from the above operation), but the core does not do this (the default value is 0), we should not Feel free to change it. Under normal circumstances, the application runs stably on the system, and the free value will remain at a stable value, although it may seem small.
When there are problems such as insufficient memory, application cannot obtain available memory, OOM error, etc., it is still more necessary to analyze the reasons for the application, such as insufficient memory due to too many users, application memory overflow, etc. Otherwise, clear the buffer and force Freeing up the free size may only temporarily shield the problem.
In my opinion, except for the case of insufficient memory, unless it is in the software development stage, the buffer needs to be temporarily cleared to judge the memory usage of the application; or the application no longer provides support, even if the application does have problems with memory, and When unavoidable, consider clearing the buffer periodically. (Unfortunately, such applications usually run on old operating system versions, and the above operations will not solve it). The server in the production environment can not consider manually releasing the memory, which will bring more problems. Remember that memory is for use, not for viewing.
Unlike windows, no matter how much your real physical memory is, he has to use the hard disk swap file to read. This is why Windows often prompts that the virtual space is insufficient. Think about how boring it is. When there is still most of the memory, take out a part of the hard disk space as memory. How can the hard disk be faster than the memory, so let's look at Linux, as long as you don't need swap space, you don't have to worry about your own memory being too small. If you often use swap a lot, you may have to consider adding physical memory, which is also the standard for Linux to see if the memory is sufficient. Of course, this only represents my personal opinion, and everyone is welcome to exchange and discuss.