Linux 内核的缓存简介

2018年6月26日 8.25k 次阅读 0 条评论 5 人点赞

目录

提笔之前,对于 Linux 的缓存与预读这个机制尚且没有一个完整的概念,只能边看边学习然后记录,这篇文章仅仅只能作为一个参考学习资料,并不能作为技术文档载入各位的知识体系,当然,作为课外阅读来讲,还是足够的,毕竟干货还是不在少数,我会一步步的深入缓存与预读的各个体系以及在某一次调试过程中与缓存以及内存碎片相关的 BUG 进入一个探讨,方便读者以及自己能够有个清晰的记忆,也是为了能够对整个知识体系有个良好的总结。

缓存机制介绍

Linux 系统中,为了提高文件系统的读写性能1,内核会利用一部分内存(相当大的剩余内存)分配缓存区,用于缓存系统操作和数据。当核外数据需要写入磁盘时,该 IO 请求将会被缓存起来,等到一个合适的时机一并写入到后端磁盘,这就是回写缓存;当核外需要读取磁盘数据时,此 IO 读请求将会一次性读取更多的数据保留到特定的缓存区域,这种预测下一次读取数据的位置方式叫做预读,他读到的数据也将保存到缓存中。他们都可以称之为缓存,缓存的核心是算法,后面的章节会稍微介绍一下当前 Linux 主流采用的缓存核心算法。缓存的好处显而易见,那么可以合并多个 IO 请求,从而减少 CPU 上下文的切换以及减少堆栈调用,同时可以提高磁盘访问效率。由于缓存的存在,内核的代码和数据结构不必单一的从磁盘读取,也不必一定强制要求立刻写入磁盘,因此页面缓存可能是下面这些类型:

  • 还有普通文件数据的页
  • 含有目录的页
  • 含有直接从块设备文件(跳过文件系统层)读取的数据页
  • 含有用户态进程数据的页,但页中数据已被交换到磁盘
  • 数据特殊文件系统的页,比如进程间通信中的特殊文件系统 shm

下图是块设备的 I/O 操作流程,从图中可以看出具体的文件系统(如 ext4 等)负责文件在 Cache 和存储设备间交换数据,位于具体文件系统之上的虚拟文件系统 VFS 负责在应用程序和文件 Cache 之间通过 read/write 等接口交换数据。

页面 Cache 中每页所包含的数据是属于某个文件(准确的说应该是文件的 inode),所有的 read/write 都依赖于页面 Cache,当然,你设置了 O_DIRECT 标志的话,页面 Cache 就会被跳过2

查看当前的系统的缓存区和内存使用情况

[root@localhost ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:          32140         280        2450           9       29409       31480
Swap:             0           0           0

上面的命令看得出,该系统存在 32G 的内存,已使用了 280M,剩余 2450M。其中 buff/cache 一共占据了 29409M,也就是说其实现在的剩余空间之所以只剩下不到 2G 就是剩下的大约 29G 都被缓存占据了,不过该命令的最后一段给出的 available 告诉的就是当前系统可用内存还剩下 31G 左右,说明 buff/cache 是可以被回收掉的,他们也是属于可用内存的一种。

缓存区 buffers 和 caches 的区别

之前一直不太懂缓存区为何还分为 buffer 和 cache 段,查了很多资料,而且不太统一,甚至连内核下的 Document 下的描述也不是很清晰,而且我还觉得是不是写错了,综合各种渠道来源的资料,我贴出一种比较认可的说法。

buffers 是用来给块设备使用的缓存区,他只记录文件系统的 metadata 以及 tacking in-flight pages;cached 是用来给文件做缓冲。意思就是说,buffers 用来存储目录里面有什么内容和权限,而 cached 用来记忆我们打开的文件。我们稍微来做一个实验,还是之前的那一台机器,我们观察 /proc/meminfo 下面的相关选项的数据变化。

[root@localhost ~]# cat /proc/meminfo
Buffers:          414412 kB
Cached:         29666920 kB

这是在当前什么都不做的情况下的一个内存使用情况,我省略了其他的部分,请仅仅关注 buffers 和 cached 这两个部分。此时我尝试 ls 观察一个目录,然后再 cat meminfo 这个文件,现在请看:

[root@localhost ~]# ls /
bin  boot  dev  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  run  sbin

[root@localhost ~]# cat /proc/meminfo
Buffers:          414420 kB
Cached:         29666920 kB

可不可以看得到,cached 并没有发生变化,仅仅只是 buffers 字段数据增加了,说明在查看目录的时候,buffers 区域保存了这个目录的一些信息,所以他占用了大约 8kb 的内容,这里的页大小为 4kb,所以应该说是刚刚的操作导致 buffers 扩展了 2 个页,所以 buffers 这个很好理解,那么我们再来看看 cached 的作用。

首先我们清理掉整个系统的非在线缓存(没有正在被处理的缓存,可以被回收的缓存),echo 1 > /proc/sys/vm/drop_caches,然后读取当前的 meminfo 信息

[root@localhost ~]# echo 1 > /proc/sys/vm/drop_caches

[root@localhost ~]# cat /proc/meminfo
Buffers:            1080 kB
Cached:            58740 kB

然后执行文件读取,再观察 meminfo

[root@localhost ~]# dd if=/root/file1 of=/dev/null

[root@localhost ~]# cat /proc/meminfo
Buffers:            1080 kB
Cached:            64168 kB

cached 字段发生了改变,是不是很清晰,当然,不仅仅是我演示的读文件会改变 cached 字段的大小,写同样也会增加或者改变这个字段的大小3,这里就不进行演示了。

释放缓存内存的方法

上面稍微提到了释放缓存区的一种方式,现在可以全面的总结如何回收缓存。

清理 pagecache(页面缓存)

[root@localhost ~]# echo 1 > /proc/sys/vm/drop_caches
或者
[root@localhost ~]# sysctl -w vm.drop_caches=1

清理 dentries(目录缓存)和 inodes

[root@localhost ~]# echo 2 > /proc/sys/vm/drop_caches
或者
[root@localhost ~]# sysctl -w vm.drop_caches=2

清理 pagecache、dentries 和 inodes

[root@localhost ~]# echo 3 > /proc/sys/vm/drop_caches
或者
[root@localhost ~]# sysctl -w vm.drop_caches=3

上面三种都是可以临时释放缓存的方法,要想永久释放缓存,需要在 /etc/sysctl.conf 中配置:vm.drop_caches=1/2/3,然后执行 sysctl -p 让设置生效即可!另外,可以使用 sync 命令来清理文件系统缓存,他还会清理掉僵尸(zombie)对象和他们所占用的内存。

vfs_cache_pressure 和 min_free_kbytes

从名字就可以看得出这两个接口的意义,一个是用来控制 cache 的回收倾向,一个是控制最小的可用 free 内存的大小,综合上面提到的 free 内存的计算方式,我们知道 free 内存就是可以交给其他程序使用的内存,这里不包括缓存,也就是说,设置这个 min_free_kbytes 的作用主要是为了防止缓存将所有的内存全部耗尽,而导致其他程序无法申请到内存而崩溃4

vfs_cache_pressure 是用来表示内核在回收的时候,对于 dentries 和 inodes 内存的回收倾向,默认值为 100,表示会根据 pagecache 和 swapcache 给出一个合适的百分比;降低该值,将导致内核倾向于更多的保留 dentries 和 inodes 的缓存内存;提高该值,将导致内核更为激进的回收掉缓存。

min_free_kbytes 前文已经将他的作用稍微说明了一次,这里主要讲一讲他的默认值,在内核源码中,他的定义位于 mm/page_alloc.c 文件中。

 /*
  * Initialise min_free_kbytes.
  *
  * For small machines we want it small (128k min).  For large machines
  * we want it large (64MB max).  But it is not linear, because network
  * bandwidth does not increase linearly with machine size.  We use
  *
  *      min_free_kbytes = 4 * sqrt(lowmem_kbytes), for better accuracy:
  *      min_free_kbytes = sqrt(lowmem_kbytes * 16)
  *
  * which yields
  *
  * 16MB:        512k
  * 32MB:        724k
  * 64MB:        1024k
  * 128MB:       1448k
  * 256MB:       2048k
  * 512MB:       2896k
  * 1024MB:      4096k
  * 2048MB:      5792k
  * 4096MB:      8192k
  * 8192MB:      11584k
  * 16384MB:     16384k
  */

通过一系列的运算,得到的如上面的表对应的一个值,左列为当前系统的内存大小,后面为 min_free_kbytes 的大小。


  1. 裸设备的读写也会走到缓存,因为在读写裸设备的时候也会走一个简单的裸设备文件系统。 ↩︎
  2. 为何会有生产程序整个放弃缓存提高性能的优势呢?其实比如某些数据库程序就会放弃页面缓存而采用自己的缓存算法,毕竟通用的缓存算法并不一定是适合每一个应用场景的 ↩︎
  3. cached 和 buffers 字段不仅仅只会增大,当达到一定的设置水位或者改变同一个文件大小的时候,这个值会随着改变,所以不要迷信只会增大,系统中有自动回收机制也会在特定的条件下回收掉部分数据,所以这个值可大可小。 ↩︎
  4. 实际运转的机器中,一般都不会遇到内存耗尽的情况,但是这个值还是不值得迷恋,因为 min_free_kbytes 在内核代码中也仅仅是一个经验值,我最近就遇到一台大内存机器,他的 min_free_kbytes 内存为 4G 左右,但是由于长时间的运行,导致这剩下的 4G 全部为内存碎片,即不存在 16KB 的连续内存,导致 iSCSI 程序无法申请到合适的连续物理内存而崩溃。 ↩︎
标签:
最后编辑:2020年12月30日