In Linux, file access and device access are usually cached to speed up access. This is the default behavior of the system. The cache consumes our memory, although this memory can be used through ECHO
3> commands such as/proc/sys/Vm/drop_caches are released. But sometimes we still need to understand who has consumed our memory.
Let's first understand the memory usage:
[root@my031045 ~]# free total used free shared buffers cachedMem: 24676836 626568 24050268 0 30884 508312-/+ buffers/cache: 87372 24589464Swap: 8385760
Page cache and buffer cache have always been two confusing concepts. On the Internet, many people are arguing about the differences between the two caches, at the end of the discussion, there was no unified and correct conclusion. During my work,
The concepts of page cache and buffer cache have plagued me, but after careful analysis, these two concepts are actually very clear. If we can understand the nature of these two caches, we may be more comfortable in analyzing Io problems.
The page cache is actually for the file system, and is the File Cache. Data at the file level is cached in the page cache. The logic layer of the file needs to be mapped to the actual physical disk. This ing relationship is completed by the file system. When the page cache data
When the page cache needs to be refreshed, the data in the page cache is handed over to the buffer cache. However, this kind of processing becomes very simple after the kernel of version 2.6, and there is no real cache operation.
Buffer cache is the cache for disk blocks, that is, if no file system is available, data directly operated on the disk will be cached in the buffer cache. For example, the metadata of the file system is cached in the buffer cache.
In short, page cache is used to cache file data, and buffer cache is used to cache disk data. In the case of a file system, operations on the file will cache the data to the page cache. If you directly use dd or other tools to read and write the disk, the data will
Cache to buffer cache. In the file system layer, each device is assigned a file operation method of def_blk_ops. This is the operation method of the device. A radix tree exists under the inode of each device, this Radix tree
The page of the cached data will be placed below. The number of pages is displayed in the buffer column of the top program. If the device has a file system,
An inode will be generated, and the inode will allocate operation methods such as ext3_ops. These methods are file system methods, and there is also a radix tree under this inode,
Here, the page of the cached file is cached. The number of cached pages is calculated in the cache column of the top program. From the above analysis, we can see that the buffer cache and page cache in the 2.6 kernel
The processing is consistent, but there are conceptual differences. The page cache is for File Cache, And the buffer is for disk block data cache.
With the great systemtap, we can use the STAP script to understand who is consuming our cache:
# This command line is used to investigate who is adding data to page_cache [root @ my031045 ~] # STAP-e 'probe VFS. add_to_page_cache {printf ("Dev = % d, devname = % s, iNO = % d, Index = % d, nrpages = % d/N", Dev, devname, Ino, index, nrpages )}'... dev = 2, devname = N/A, iNO = 0, Index = 2975, nrpages = 1777dev = 2, devname = N/A, iNO = 0, Index = 3399, nrpages = 2594dev = 2, devname = N/A, iNO = 0, Index = 3034, nrpages = 1778dev = 2, devname = N/A, iNO = 0, Index = 3618, nrpages = 2595dev = 2, devname = N/A, iNO = 0, Index = 1694, nrpages = offline Dev = 2, devname = N/A, iNO = 0, Index = 1703, nrpages = paidev = 2, devname = N/A, iNO = 0, Index = 1810, nrpages = 210dev = 2, devname = N/A, iNO = 0, Index = 1812, nrpages = 211...
At this time, we copy a large file:
[Chuba @ my031045 ~] $ CP huge_foo.file bar # at this time, we can see that the file content is added to the cache :... dev = 8388614, devname = sda6, iNO = 2399271, Index = 39393, nrpages = 39393dev = 8388614, devname = sda6, iNO = 2399271, Index = 39394, nrpages = 39394dev = 8388614, devname = sda6, iNO = 2399271, Index = 39395, nrpages = 39395dev = 8388614, devname = sda6, iNO = 2399271, Index = 39396, nrpages = 3920.dev = 8388614, devname = sda6, ino = 2399271, Index = 39397, nrpages = 3920.dev = 8388614, devname = sda6, iNO = 2399271, Index = 39398, nrpages = 39398dev = 8388614, devname = sda6, iNO = 2399271, index = 39399, nrpages = 39399dev = 8388614, devname = sda6, iNO = 2399271, Index = 39400, nrpages = 39400dev = 8388614, devname = sda6, iNO = 2399271, Index = 39401, nrpages = 39401dev = 8388614, devname = sda6, iNO = 2399271, Index = 39402, nrpages = 39402dev = 8388614, devname = sda6, iNO = 2399271, Index = 39403, nrpages = 39403dev = 8388614, devname = sda6, iNO = 2399271, Index = 39404, nrpages = 39404dev = 8388614, devname = sda6, iNO = 2399271, Index = 39405, nrpages = 39405dev = 8388614, devname = sda6, iNO = 2399271, Index = 39406, nrpages = 39406dev = 8388614, devname = sda6, iNO = 2399271, Index = 39407, nrpages = 39407dev = 8388614, devname = sda6, iNO = 2399271, Index = 39408, nrpages = 39408dev = 8388614, devname = sda6, iNO = 2399271, Index = 39409, nrpages = 39409dev = 8388614, devname = sda6, iNO = 2399271, Index = 39410, nrpages = 3920.dev = 8388614, devname = sda6, iNO = 2399271, Index = 39411, nrpages = 39411...