Linux性能优化从入门到实战：10 内存篇：如何利用Buffer和Cache优化程序的运行效率？

缓存命中率

缓存命中率，是指直接通过缓存获取数据的请求次数，占所有数据请求次数的百分比，可以衡量缓存使用的好坏。命中率越高，表示使用缓存带来的收益越高，应用程序的性能也就越好。

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

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

cachetop 提供了每个进程的缓存命中情况。

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

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 4052245BD4284CDD

$ echo "deb https://repo.iovisor.org/apt/xenial xenial main" | sudo tee /etc/apt/sources.list.d/iovisor.list

$ sudo apt-get update

$ sudo apt-get install -y bcc-tools libbcc-examples linux-headers-$(uname -r)

# 注意：bcc-tools 需要内核版本为 4.1 或者更新的版本，

# 如果你用的是 CentOS，那就需要手动升级内核版本后再安装(https://github.com/iovisor/bcc/issues/462)

# 所有工具就都安装到 /usr/share/bcc/tools 这个目录中

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

cachestat 以 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

# TOTAL ，表示总的 I/O 次数；

# MISSES ，表示缓存未命中的次数；

# HITS ，表示缓存命中的次数；

# DIRTIES， 表示新增到缓存中的脏页数；

# BUFFERS_MB 表示 Buffers 的大小，以 MB 为单位；

# CACHED_MB 表示 Cache 的大小，以 MB 为单位。

cachetop 的运行界面：

$ cachetop

11:58:50 Buffers MB: 258 / Cached MB: 347 / Sort: HITS / Order: ascending

PID      UID      CMD              HITS     MISSES   DIRTIES  READ_HIT%  WRITE_HIT%

   13029 root     python                  1        0        0     100.0%       0.0%

# HITS ，间隔时间内的缓存命中次数

# MISSES ，间隔时间内的未命中次数

# DIRTIES ，新增到缓存中的脏页数

# READ_HIT / WRITE_HIT ，读和写的缓存命中率

指定文件的缓存大小

除了缓存的命中率外，还有一个指标就是指定文件在内存中的缓存大小。

pcstat (https://github.com/tobert/pcstat) 查看文件在内存中的缓存大小以及缓存比例。

$ export GOPATH=~/go

$ export PATH=~/go/bin:$PATH

$ go get golang.org/x/sys/unix

$ go get github.com/tobert/pcstat/pcstat

$ pcstat /bin/ls

+---------+----------------+------------+-----------+---------+

| Name    | Size (bytes)   | Pages      | Cached    | Percent |

|---------+----------------+------------+-----------+---------|

| /bin/ls | 133792         | 33         | 0         | 000.000 |

+---------+----------------+------------+-----------+---------+

# Cached 就是 /bin/ls 在缓存中的大小，而 Percent 则是缓存的百分比。

# 你看到它们都是 0，这说明 /bin/ls 并不在缓存中。

$ ls

$ pcstat /bin/ls

+---------+----------------+------------+-----------+---------+

| Name    | Size (bytes)   | Pages      | Cached    | Percent |

|---------+----------------+------------+-----------+---------|

| /bin/ls | 133792         | 33         | 33        | 100.000 |

+---------+----------------+------------+-----------+---------+

案例一

dd 作为一个磁盘和文件的拷贝工具，经常被拿来测试磁盘或者文件系统的读写性能。

# 生成一个 512MB 的临时文件

$ dd if=/dev/sda1 of=file bs=1M count=512

# 清理缓存

$ echo 3 > /proc/sys/vm/drop_caches

# 确认刚刚生成的文件不在缓存中

$ pcstat file

+-------+----------------+------------+-----------+---------+

| Name  | Size (bytes)   | Pages      | Cached    | Percent |

|-------+----------------+------------+-----------+---------|

| file  | 536870912      | 131072     | 0         | 000.000 |

+-------+----------------+------------+-----------+---------+

实验检测缓存对文件读取性能的影响：

# 第一个 terminal 中每隔 5 秒刷新一次数据

$ cachetop 5

# 第一个 terminal 中运行 dd 命令测试文件的读取速度

$ dd if=file of=/dev/null bs=1M

512+0 records in

512+0 records out

536870912 bytes (537 MB, 512 MiB) copied, 16.0509 s, 33.4 MB/s

# 第一个 terminal 输出

PID      UID      CMD              HITS     MISSES   DIRTIES  READ_HIT%  WRITE_HIT%

\.\.\.

    3264 root     dd                  37077    37330        0      49.8%      50.2%

这个文件的读性能是 33.4 MB/s。由于在 dd 命令运行前我们已经清理了缓存，所以 dd 命令读取数据时，肯定要通过文件系统从磁盘中读取。并且 cachetop 的结果可以发现，并不是所有的读都落到了磁盘上，事实上读请求的缓存命中率只有 50% 。

继续尝试相同的测试命令，系统缓存可以大大提高文件读取的性能。

$ dd if=file of=/dev/null bs=1M

512+0 records in

512+0 records out

536870912 bytes (537 MB, 512 MiB) copied, 0.118415 s, 4.5 GB/s

# 第一个 terminal 输出

10:45:22 Buffers MB: 4 / Cached MB: 719 / Sort: HITS / Order: ascending

PID      UID      CMD              HITS     MISSES   DIRTIES  READ_HIT%  WRITE_HIT%

\.\.\.

   32642 root     dd                 131637        0        0     100.0%       0.0%

$ pcstat file

+-------+----------------+------------+-----------+---------+

| Name  | Size (bytes)   | Pages      | Cached    | Percent |

|-------+----------------+------------+-----------+---------|

| file  | 536870912      | 131072     | 131072    | 100.000 |

+-------+----------------+------------+-----------+---------+

特别提醒：但同时也要注意，如果我们把 dd 当成测试文件系统性能的工具，由于缓存的存在，就会导致测试结果严重失真。

案例二

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

# 第一个 terminal 每隔 5 秒刷新一次数据

$ cachetop 5

# 第二个 terminal

$ docker run --privileged --name=app -itd feisky/app:io-direct

$ docker logs app

Reading data from disk /dev/sdb1 with buffer size 33554432

Time used: 0.929935 s to read 33554432 bytes

# 回到第一个 terminal

16:39:18 Buffers MB: 73 / Cached MB: 281 / Sort: HITS / Order: ascending

PID      UID      CMD              HITS     MISSES   DIRTIES  READ_HIT%  WRITE_HIT%

   21881 root     app                  1024        0        0     100.0%       0.0%

实验结果是，每读取 32 MB 的数据，就需要花 0.9 秒，第一反应就是，太慢了。并且 1024 次缓存全部命中，读的命中率是 100%，看起来全部的读请求都经过了系统缓存。但是问题又来了，如果真的都是缓存 I/O，读取速度不应该这么慢。

每秒实际读取的数据大小：HITS 代表缓存的命中次数，每次命中能读取一页数据（内存以页为单位进行管理），每个页的大小是 4KB，在 5 秒的时间间隔里，命中的缓存为 1024*4K/1024 = 4MB，再除以 5 秒，可以得到每秒读的缓存是 0.8MB，显然跟案例应用的 32 MB/s 相差太多。

这个案例估计没有充分利用系统缓存，如果为系统调用设置直接 I/O 的标志，就可以绕过系统缓存。并且直接从磁盘读写的速度，自然远慢于对缓存的读写。

通过观察程序的系统调用，可以了解是否用了直接 I/O，工具是 strace。

# strace -p $(pgrep app)

strace: Process 4988 attached

restart_syscall(<\.\.\. resuming interrupted nanosleep \.\.\.>) = 0

openat(AT_FDCWD, "/dev/sdb1", O_RDONLY|O_DIRECT) = 4

mmap(NULL, 33558528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f448d240000

read(4, "8vq\213\314\264u\373\4\336K\224\25@\371\1\252\2\262\252q\221\n0\30\225bD\252\266@J"\.\.\., 33554432) = 33554432

write(1, "Time used: 0.948897 s to read 33"\.\.\., 45) = 45

close(4)                                = 0

删除 O_DIRECT 标志后，性能得到提高。每次只需要 0.03 秒，就可以读取 32MB 数据，明显比之前的 0.9 秒快多了。所以，这次应该用了系统缓存。

$ docker logs app

Reading data from disk /dev/sdb1 with buffer size 33554432

Time used: 0.037342 s s to read 33554432 bytes

Time used: 0.029676 s to read 33554432 bytes

观察 cachetop 的输出：

16:40:08 Buffers MB: 73 / Cached MB: 281 / Sort: HITS / Order: ascending

PID      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 都是操作系统来管理的，应用程序并不能直接控制这些缓存的内容和生命周期。所以，在应用程序开发中，一般要用专门的缓存组件，来进一步提升性能。比如，程序内部可以使用堆或者栈明确声明内存空间，来存储需要缓存的数据。再或者，使用 Redis 这类外部缓存服务，优化数据的访问效率。

PS: Centos 安装 bcc-tools

yum update -y  # 升级系统

rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org  # 安装 ELRepo

rpm -Uvh https://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm

yum remove -y kernel-headers kernel-tools kernel-tools-libs  # 安装新内核

yum --enablerepo="elrepo-kernel" install -y kernel-ml kernel-ml-devel kernel-ml-headers kernel-ml-tools kernel-ml-tools-libs kernel-ml-tools-libs-devel

grub2-mkconfig -o /boot/grub2/grub.cfg  # 更新 Grub 后重启

grub2-set-default 0

reboot

uname -r  # 重启后确认内核版本已升级为 4.20.0-1.el7.elrepo.x86_64

yum install -y bcc-tools  # 安装 bcc-tools

export PATH=$PATH:/usr/share/bcc/tools  # 配置 PATH 路径

cachestat  # 验证安装成功