Linux cache memory (caching) mechanism

Ext: 79177036

PS: Why does the Linux system not run many programs, showing so little available memory? In fact, Linux and win memory management is different, will try to cache memory to improve read and write performance, usually called cache memory.

Why does the Linux system not run many programs and shows so little available memory? In fact, Linux and win memory management is different, will try to cache memory to improve read and write performance, usually called cache memory.

Sometimes you will find that there is no program running, but using the top or the free command to see the available memory is very small, when viewing the system's/proc/meminfo file, you will find a Cached memory:
Enter Cat/proc/meminfo view:

memtotal:16425996 kb memfree:5698808 KB buffers:380904 kb cached:9389356 KB swapcached:212 KB active:6569200 KB inactive:3725364 KB hightotal:0 KB highfree:0 KB lowtotal:16425996 KB lowfree:5698808 KB swaptotal:8273464 KB swapfree:8273252 KB dirty:980 KB Wr    iteback:0 KB anonpages:524108 KB mapped:24568 KB slab:381776 KB pagetables:7496 KB nfs_unstable:0 kb bounce:0 KB commitlimit:16486460 KB committed_as:2143856 KB vmalloctotal:34359738367 KB vmallocused:26 7656 KB vmallocchunk:34359469303 KB hugepages_total:0 hugepages_free:0 hugepages_rsvd:0 hugepagesize:2 048 KB  

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21st
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31

Description of the various memory metrics in the free command:

total used free shared buffers cachedMem: 16425996 10727220 5698776 0 380904 9389832-/+ buffers/cache: 956484 15469512Swap: 8273464 212 8273252

• 1
• 2
• 3
• 4
• 5

The first line describes the memory state used by the system in a global perspective:
total--Total Physical Memory
used--already uses memory, this value is generally larger because this value includes the memory used by the cache+ application
free--memory that is not fully used
shared--Application Shared Memory
buffers--cache, mainly used for directory aspects, Inode value, etc. (LS Large directory can see this value increase)
cached--cache, for files that have been opened
Summarize:
Total=used+free
Used=buffers+cached (maybe add shared also)

The second line describes the memory usage of the application:
The previous value indicates the memory size used by the-buffers/cache--application, used minus the cached value
The latter value indicates the amount of memory +buffers/cache--all available to the application, free plus the cached value
Summarize:
-buffers/cache=used-buffers-cached
+buffers/cache=free+buffers+cached

The third line represents the use of swap:
used--already in use
free--not used

What is cache memory (cached RAM):

When you read and write files, the Linux kernel caches the files in memory in order to improve read and write performance and speed, which is the memory (cache memory). The Cache memory will not be released automatically even after your program has finished running. This will cause you to read and write files frequently in your Linux system, and you will find that there is little physical memory available.

In fact, this cache memory is automatically released when you need to use memory, so you don't have to worry about not having memory available. If you want to release the cache memory manually, there is a way.

How to release the cache memory (cached RAM):

Use the following command to release the cache Memory:

To free pagecache:echo 1 > /proc/sys/vm/drop_cachesTo free dentries and inodes:echo 2 > /proc/sys/vm/drop_cachesTo free pagecache, dentries and inodes:echo 3 > /proc/sys/vm/drop_caches

• 1
• 2
• 3
• 4
• 5
• 6
• 7

Note that it is best to sync before releasing to prevent data loss.

Summary: Personal experience that there is no need to manually release, this memory management method is also better than win one of the places! Because of the kernel memory management mechanism of Linux, it is generally not necessary to deliberately release the cache that is already in use. These cache contents can improve the read and write speed of files and disks.

Page caching--the memory and file of the thing

Referring to the file, the operating system must address two important issues. The first is that the hard drive has a very slow access speed (relative to memory), especially the disk's seek performance. The second is to meet the ' one-time loading of file contents into physical memory and sharing between programs ' needs. If you use the process browser to look through the Windows process, you will find that about 15MB of shared DLLs are loaded into each process. My current Windows system runs 100 processes, and if there is no sharing mechanism, it consumes about 1.5GB of physical memory just to hold the public DLLs. This is not very good. Similarly, almost all Linux programs require ld.so and LIBC, as well as other common function libraries.

Happily, these two problems can be solved by stone: page cache, which is used by the kernel to store file data blocks of the same size as the page. To show the page cache, I need to sacrifice a Linux program called Render, which opens a Scene.dat file, reads 512 bytes each time, and saves the content to a block of memory built on the heap. The first reading is this:

After reading 12KB, the heap of the render and related page frames are as follows:

It seems simple, but there are a lot of things that can happen. First, even if the program calls only the regular read function, three 4KB page frames are stored in the page cache, which holds part of the Scene.dat data. Although this is sometimes surprising, it is true that all regular file I/O is done through the page cache. In x86 Linux, the kernel sees a file as a sequence of 4KB-sized chunks of data. Even if you read only one byte from a file, the entire 4KB data block containing the byte is read and placed into the page cache. This makes sense because the persistent data throughput of the disk is good, and in general, the program reads more than a few bytes into a region of the file. The page cache knows the corresponding location of each 4KB data block in the file, as shown in the #0, #1等等. Similar to the Linux page cache, Windows uses 256KB views.

Unfortunately, in a normal file read operation, the kernel must replicate the contents of the page cache into a user buffer, which not only consumes CPU time, hurts CPU cache performance, but also wastes physical memory because of the duplication of information stored. As shown in each picture above, the contents of Scene.dat are saved two times, and each instance of the program is saved in one copy. At this point, we mitigated the problem of disk latency, but failed miserably on each of the remaining issues. Memory-mapped files (memory-mapped files) will lead us out of chaos:

When you use file mapping, the kernel maps your program's virtual memory pages directly to the page cache. This leads to a significant performance boost: Windows system programming indicates that regular file read operations have improved performance by more than 30%; advanced programming in the UNIX environment indicates that similar situations occur on Linux and Solaris systems. You may also save a lot of physical memory, depending on the specifics of your program.

As before, performance is the real measure, but memory mapping is really worth being put into the toolbox by programmers. The associated API is also beautiful, providing access to a file in the same way that it accesses bytes in memory, without the need for you to worry about it or to compromise the readability of your code. Recall the address space, and the experiment on Mmap on Unix-like systems, createfilemapping in Windows and its various available packages in high-level languages. When you map a file, its content is not immediately fully loaded into memory, but instead relies on page failure (page fault) to read on demand. After you get a page frame that contains the required file data, the corresponding fault-handling function maps your virtual memory page to the page cache. If the required content is not in the cache, this procedure will also contain disk I/O operations.

Now give you a popular quiz. Imagine that when the last instance of the render program exits, will the cached page caches be cleaned up scene.dat? People usually think so, but it's a bad idea. If you think about it, we often create a file in a program, exit, and then use the file in the second program. The page cache must be able to handle this kind of situation. If you think about it, why should the kernel always discard the content in the page cache? Remember, disks are 5 orders of magnitude slower than RAM, so a hit on a page cache can mean a huge victory. As long as there is enough free physical memory, the cache should remain as full as possible. So it's not related to a particular process, it's a system-level resource. It would be nice if you ran the render a week ago and Scene.dat is still in the cache. This is why the size of the kernel cache increases steadily until the cache limit is reached. This is not because the operating system is junk, devouring your RAM, in fact it is a good behavior, but the release of physical memory is a waste. The more the cache is used, the better.

Because of the use of the page cache architecture, when a program calls write (), the associated bytes are simply copied into the page cache, and the page is marked as dirty (dirty). Disk I/O generally does not occur immediately, so your program execution is not interrupted to wait for the disk device. The disadvantage of this is that if the computer freezes at this point, then the data you write will not be recorded. Therefore, important files, such as database transaction records, must be Fsync () (but also be careful with disk controller caching). On the other hand, read operations usually interrupt your program until you have the required data ready. The kernel typically uses a positive loading (eager loading) approach to mitigate this problem. As an example of early reading (read ahead), the kernel will preload some pages into the page cache and look for your read operations. By prompting the system to make a sequential or random read of the file (see Madvise (), ReadAhead (), Windows cache hint), you can help the kernel adjust its aggressive loading behavior. Linux does prefetch memory-mapped files, but I'm not sure if Windows is the same. Finally, you can bypass page caching by using O_direct in Linux or using no_buffering in Windows, which is what some database software does.

A file map can be private or shared (GKFX). The difference here is only apparent when you change (update) The contents of the memory: in a private map, the changes are not committed to disk or visible to other processes, which occurs in shared mappings. The kernel uses copy on write technology to implement private mappings through page table entries (entries). In the following example, render and another program called Render3d (Am I very creative?). ) at the same time the private mapped scene.dat. The render overwrites the area of the virtual memory mapped to this file:

The Read-only page table entries shown do not imply that the mappings are read-only, they are just tricks of the kernel to share physical memory until the last possible moment. You'll find how inappropriate the word ' private ' is, and you just need to remember that it only works when the data changes. One result of this design is that a virtual memory page that maps a file privately can observe changes made to the file by other processes, as long as the memory page was previously read. Once a write-time copy has occurred, no other process changes have been observed for this file. This behavior is not provided by the kernel, but is the case on the x86 system. Also, from the API's point of view, this is reasonable. In contrast, a shared mapping simply maps to the page cache, and that's it. All changes to the page are visible to other processes, and eventually disk operations are performed. Finally, if this shared mapping is read-only, then a page fault will trigger a segment error (segmentation fault) instead of a write-time copy.

A dynamically loaded library of functions is placed into the address space of your program through a file mapping mechanism. There's nothing special about this, it's also a private file mapping, with the regular API indistinguishable that is provided to you for invocation. The following example shows a portion of the address space of two running render programs, as well as physical memory. It ties together the concepts we've seen before.

Linux cache memory (caching) mechanism