如何利用系统缓存优化程序运行效率？

如何利用系统缓存优化程序运行效率？

Buffer和Cache的设计目的，是为了提升系统的I/O性能。它们利用内存，充当慢速磁盘与快速CPU之间的桥梁，可以加速I/O访问速度。

Buffer和Cache分别缓存的是对磁盘和文件的读写数据。

写角度：不仅可以优化磁盘和文件写入，对应用程序也有好处，应用程序可以在数据真正落盘前，就返回去做其他工作。读角度：不仅可以提高那些频繁访问数据的读取速度，也降低了频繁I/O对磁盘的压力。

一、环境准备

机器配置：2 CPU，8GB 内存。预先安装 bcc 和 pcstat 软件包，并把这些工具的安装路径添加到到 PATH 环境变量中。预先安装 Docker 软件包，比如 ​​apt-get installdocker.io​​

二、缓存命中率

缓存命中率：直接通过缓存获取数据的请求次数，占所有数据请求次数的百分比。

命中率越高，表示使用缓存带来的收益越高，应用程序的性能也就越好。

实际上，缓存是现在所有高并发系统必需的核心模块，主要作用就是把经常访问的数据（也就是热点数据），提前读入到内存中。这样，下次访问时就可以直接从内存读取数据，而不需要经过硬盘，从而加快应用程序的响应速度。

查看系统缓存命中情况的工具：

​​cachestat​​ 提供了整个操作系统缓存的读写命中情况。​​cachetop​​ 提供了每个进程的缓存命中情况。

这两个工具都是 bcc 软件包的一部分，它们基于 Linux 内核的 eBPF（extended Berkeley Packet Filters）机制，来跟踪内核中管理的缓存，并输出缓存的使用和命中情况。

安装bcc软件包，系统环境：Ubuntu系统

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 4052245BD4284CDDecho "deb xenial main" | sudo tee /etc/apt/sources.list.d/iovisor.listsudo apt-get updatesudo apt-get install -y bcc-tools libbcc-examples linux-headers-$(uname -r)

注意：bcc-tools 需要内核版本为 4.1 或者更新的版本，如果你用的是 CentOS，那就需要手动​​升级内核版本​​后再安装。

操作完这些步骤，bcc 提供的所有工具就都安装到 ​​/usr/share/bcc/tools​​ 这个目录中，但bcc 软件包默认不会把这些工具配置到系统的 PATH 路径中

$ export PATH=$PATH:/usr/share/bcc/tools

配置完就可以使用了，如下：

# 1秒的时间间隔，输出3组缓存统计数据$ cachestat 1 3 TOTAL MISSES HITS DIRTIES BUFFERS_MB CACHED_MB 2 0 2 1 17 279 2 0 2 1 17 279 2 0 2 1 17 279

​​cachestat​​ 的输出其实是一个表格。每行代表一组数据，而每一列代表不同的缓存统计指标。

​​TOTAL​​ ，表示总的 I/O 次数；​​MISSES​​ ，表示缓存未命中的次数；​​HITS​​ ，表示缓存命中的次数；​​DIRTIES​​， 表示新增到缓存中的脏页数；​​BUFFERS_MB​​ 表示​​Buffers​​ 的大小，以 MB 为单位；​​CACHED_MB​​ 表示 Cache 的大小，以 MB 为单位。

$ cachetop11:58:50 Buffers MB: 258 / Cached MB: 347 / Sort: HITS / Order: ascendingPID UID CMD HITS MISSES DIRTIES READ_HIT% WRITE_HIT% 13029 root python 1 0 0 100.0% 0.0%

它的输出跟 top 类似，默认按照缓存的命中次数（HITS）排序，展示了每个进程的缓存命中情况。具体到每一个指标，这里的 HITS、MISSES 和 DIRTIES ，跟 cachestat 里的含义一样，分别代表间隔时间内的缓存命中次数、未命中次数以及新增到缓存中的脏页数。而 READ_HIT 和 WRITE_HIT ，分别表示读和写的缓存命中率。

三、指定文件的缓存大小

利用​​pcstat​​工具来查看文件在内存中的缓存大小以及缓存比例。

pcstat是基于Go语言开发的工具，安装它之前，首先应该​​安装Go语言​​。

安装完Go语言，再运行下面的命令安装​​pcstat​​：

$ export GOPATH=~/go$ export PATH=~/go/bin:$PATH$ go get golang.org/x/sys/unix$ go get github.com/tobert/pcstat/pcstat

注意：上述命令如果无法安装完成，可去​​pcstat Github​​查阅并安装

全部安装完成后，你就可以运行 pcstat 来查看文件的缓存情况了。比如，下面就是一个 pcstat 运行的示例，它展示了 ​​/bin/ls​​ 这个文件的缓存情况：

$ pcstat /bin/ls+---------+----------------+------------+-----------+---------+| Name | Size (bytes) | Pages | Cached | Percent ||---------+----------------+------------+-----------+---------|| /bin/ls | 133792 | 33 | 0 | 000.000 |+---------+----------------+------------+-----------+---------+

输出中，Cached就是/bin/ls在缓存中的大小，Percent则是缓存的百分比。看到是0，说明/bin/ls并不在缓存中。

接着，如果你执行一下 ls 命令，再运行相同的命令来查看的话，就会发现 /bin/ls 都在缓存中了：

$ ls$ pcstat /bin/ls+---------+----------------+------------+-----------+---------+| Name | Size (bytes) | Pages | Cached | Percent ||---------+----------------+------------+-----------+---------|| /bin/ls | 133792 | 33 | 33 | 100.000 |+---------+----------------+------------+-----------+---------+

四、案例一

dd 作为一个磁盘和文件的拷贝工具，经常被拿来测试磁盘或者文件系统的读写性能。不过，既然缓存会影响到性能，如果用 dd 对同一个文件进行多次读取测试，测试的结果会怎么样呢？

使用dd命令生成一个临时文件，用于后面文件读取测试：

# 生成一个512MB的临时文件$ dd if=/dev/sda1 of=file bs=1M count=512# 清理缓存$ echo 3 > /proc/sys/vm/drop_caches

4.1、终端一：运行​​pcstat​​命令，确认刚刚生成的文件不在缓存中，如果一切正常，可以看到Cached 和 Percent 都是 0

$ pcstat file+-------+----------------+------------+-----------+---------+| Name | Size (bytes) | Pages | Cached | Percent ||-------+----------------+------------+-----------+---------|| file | 536870912 | 131072 | 0 | 000.000 |+-------+----------------+------------+-----------+---------+

4.2、终端一：运行​​cachetop​​命令

# 每隔5秒刷新一次数据$ cachetop 5

4.3、终端二：运行dd命令测试文件读取速度

$ dd if=file of=/dev/null bs=1M512+0 records in512+0 records out536870912 bytes (537 MB, 512 MiB) copied, 16.0509 s, 33.4 MB/s

从 dd 的结果可以看出，这个文件的读性能是 33.4 MB/s。由于在 dd 命令运行前我们已经清理了缓存，所以 dd 命令读取数据时，肯定要通过文件系统从磁盘中读取。不过，这是不是意味着， dd 所有的读请求都能直接发送到磁盘呢？

4.4、终端一：查看cachetop界面的缓存命中情况

PID UID CMD HITS MISSES DIRTIES READ_HIT% WRITE_HIT%\.\.\. 3264 root dd 37077 37330 0 49.8% 50.2%

从 cachetop 的结果可以发现，并不是所有的读都落到了磁盘上，事实上读请求的缓存命中率只有 50% 。

4.5、终端二：执行刚刚dd命令

$ dd if=file of=/dev/null bs=1M512+0 records in512+0 records out536870912 bytes (537 MB, 512 MiB) copied, 0.118415 s, 4.5 GB/s

磁盘的读性能居然变成了 4.5 GB/s，比第一次的结果明显高了太多。为什么这次的结果这么好呢？

4.6、终端一：看看 cachetop 的情况：

10:45:22 Buffers MB: 4 / Cached MB: 719 / Sort: HITS / Order: ascendingPID UID CMD HITS MISSES DIRTIES READ_HIT% WRITE_HIT%\.\.\. 32642 root dd 131637 0 0 100.0% 0.0%

显然，cachetop 也有了不小的变化。可以发现，这次的读的缓存命中率是 100.0%，也就是说这次的 dd 命令全部命中了缓存，所以才会看到那么高的性能。

4.7、终端二：再次执行 pcstat 查看文件 file 的缓存情况

$ pcstat file+-------+----------------+------------+-----------+---------+| Name | Size (bytes) | Pages | Cached | Percent ||-------+----------------+------------+-----------+---------|| file | 536870912 | 131072 | 131072 | 100.000 |+-------+----------------+------------+-----------+---------+

从 pcstat 的结果可以发现，测试文件 file 已经被全部缓存了起来，这跟刚才观察到的缓存命中率 100% 是一致的。

这两次结果说明，系统缓存对第二次 dd 操作有明显的加速效果，可以大大提高文件读取的性能。

注意：如果把 dd 当成测试文件系统性能的工具，由于缓存的存在，就会导致测试结果严重失真。

五、案例二

每秒从磁盘分区 ​​/dev/sda1​​ 中读取 32MB 的数据，并打印出读取数据花费的时间。

运行​​Docker​​镜像执行环境。案例提供了如下两个选项，可以根据系统配置，自行调整磁盘分区的路径以及I/O大小。

​​-d​​选项：设置要读取的磁盘或分区路径，默认是查找前缀为 /dev/sd 或者 /dev/xvd 的磁盘。​​-s​​选项：设置每次读取的数据量大小，单位为字节，默认为 33554432（也就是 32MB）。

5.1、终端一：运行​​cachetop​​命令

# 每隔5秒刷新一次数据$ cachetop 5

5.2、终端二：运行下列命令

$ git clone git@gitee.com:liushiju/linux_performance_examples.git$ cd linux_performance_examples/io-cached$ make build$ make runor$ docker run --privileged --name=app -itd shijuliu/app:io-direct

案例运行后，还需要运行如下命令，来确认案例已经正常启动。如果一切正常，应该可以看到类似下面输出

$ docker logs appReading data from disk /dev/sdb1 with buffer size 33554432Time used: 0.929935 s to read 33554432 bytesTime used: 0.949625 s to read 33554432 bytes

可以看到，每读取 32 MB 的数据，就需要花 0.9 秒。这个时间合理吗？第一反应该就是，太慢了吧。那这是不是没用系统缓存导致的呢？

5.3、终端一：先看看 ​​cachetop​​ 的输出，在这里，我们找到案例进程 app 的缓存使用情况

16:39:18 Buffers MB: 73 / Cached MB: 281 / Sort: HITS / Order: ascendingPID UID CMD HITS MISSES DIRTIES READ_HIT% WRITE_HIT% 21881 root app 1024 0 0 100.0% 0.0%

1024 次缓存全部命中，读的命中率是 100%，看起来全部的读请求都经过了系统缓存。但是问题又来了，如果真的都是缓存 I/O，读取速度不应该这么慢。

似乎忽略了另一个重要因素，每秒实际读取的数据大小。HITS 代表缓存的命中次数，那么每次命中能读取多少数据呢？自然是一页。

内存以页为单位进行管理，而每个页的大小是 4KB。所以，在 5 秒的时间间隔里，命中的缓存为 1024*4K/1024 = 4MB，再除以 5 秒，可以得到每秒读的缓存是 0.8MB，显然跟案例应用的 32 MB/s 相差太多。

这个案例估计没有充分利用系统缓存。其实前面也遇到过类似的问题，如果为系统调用设置直接 I/O 的标志，就可以绕过系统缓存。

那么，要判断应用程序是否用了直接 I/O，最简单的方法就是观察它的系统调用，查找应用程序在调用它们时的选项。

5.4、终端二：运行​​strace​​​命令，观察案例应用的系统调用情况。注意，这里使用了​​pgrep​​命令还查找案例进程的PID号

# strace -p $(pgrep app)strace: Process 4988 attachedrestart_syscall(<\.\.\. resuming interrupted nanosleep \.\.\.>) = 0openat(AT_FDCWD, "/dev/sdb1", O_RDONLY|O_DIRECT) = 4mmap(NULL, 33558528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f448d240000read(4, "8vq\213\314\264u\373\4\336K\224\25@\371\1\252\2\262\252q\221\n0\30\225bD\252\266@J"\.\.\., 33554432) = 33554432write(1, "Time used: 0.948897 s to read 33"\.\.\., 45) = 45close(4) = 0

从 strace 的结果可以看到，案例应用调用了 ​​openat​​​ 来打开磁盘分区 ​​/dev/sdb1​​​，并且传入的参数为 ​​O_RDONLY|O_DIRECT​​（中间的竖线表示或）。

O_RDONLY 表示以只读方式打开，而 O_DIRECT 则表示以直接读取的方式打开，这会绕过系统的缓存。

验证了这一点，就很容易理解为什么读 32 MB 的数据就都要那么久了。直接从磁盘读写的速度，自然远慢于对缓存的读写。这也是缓存存在的最大意义了。

找出问题后，我们还可以在再看看案例应用的​​源代码​​，再次验证一下:

int flags = O_RDONLY | O_LARGEFILE | O_DIRECT; int fd = open(disk, flags, 0755);

上面的代码，很清楚地告诉我们：它果然用了直接 I/O。

找出了磁盘读取缓慢的原因，优化磁盘读的性能自然不在话下。修改源代码，删除 O_DIRECT 选项，让应用程序使用缓存 I/O ，而不是直接 I/O，就可以加速磁盘读取速度。

5.5、终端二：运行修复后的源码

# 删除上述案例应用$ docker rm -f app# 运行修复后的应用$ docker run --privileged --name=app -itd shijuliu/app:io-cached$ docker logs appReading data from disk /dev/sdb1 with buffer size 33554432Time used: 0.037342 s s to read 33554432 bytesTime used: 0.029676 s to read 33554432 bytes

现在，每次只需要 0.03 秒，就可以读取 32MB 数据，明显比之前的 0.9 秒快多了。所以，这次应该用了系统缓存。

5.6、终端一：查看 ​​cachetop​​ 的输出来确认一下

16:40:08 Buffers MB: 73 / Cached MB: 281 / Sort: HITS / Order: ascendingPID UID CMD HITS MISSES DIRTIES READ_HIT% WRITE_HIT% 22106 root app 40960 0 0 100.0% 0.0%

果然，读的命中率还是 100%，HITS （即命中数）却变成了 40960，同样的方法计算一下，换算成每秒字节数正好是 32 MB（即 40960*4k/5/1024=32M）。

这个案例说明，在进行 I/O 操作时，充分利用系统缓存可以极大地提升性能。 但在观察缓存命中率时，还要注意结合应用程序实际的 I/O 大小，综合分析缓存的使用情况。

案例的最后，再回到开始的问题，为什么优化前，通过 cachetop 只能看到很少一部分数据的全部命中，而没有观察到大量数据的未命中情况呢？这是因为，cachetop 工具并不把直接 I/O 算进来。这也又一次说明了，了解工具原理的重要。

六、总结

Buffers 和 Cache 可以极大提升系统的 I/O 性能。通常，我们用缓存命中率，来衡量缓存的使用效率。命中率越高，表示缓存被利用得越充分，应用程序的性能也就越好。

可以用 cachestat 和 cachetop 这两个工具，观察系统和进程的缓存命中情况。其中，

cachestat 提供了整个系统缓存的读写命中情况。cachetop 提供了每个进程的缓存命中情况。

注意，Buffers 和 Cache 都是操作系统来管理的，应用程序并不能直接控制这些缓存的内容和生命周期。所以，在应用程序开发中，一般要用专门的缓存组件，来进一步提升性能。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。