内存性能中 Buffer和Cache的概念
Buffer和Cache的设计目的,是为了提升系统的I/O性能。它们利用内存,充当起慢速磁盘与快速CPU之间的桥梁,可以加速 I/O的访问速度。
Buffer和Cache 分别缓存的是对磁盘和文件系统的读写数据。
- 从写的角度来说,不仅可以优化磁盘和文件的写入,对应用程序也有好处,应用程序可以在数据真正落盘前,就返回去做其他工作。
- 从读的角度来说,不仅可以提高那些频繁访问数据的读取速度,也降低了频繁I/O对磁盘的压力。
既然Buffer和Cache 对系统性能有很大影响,那我们在软件开发的过程中,能不能利用这一点,来优化I/0性能,提升应用程序的运行效率呢?
既然Buffer和Cache 对系统性能有很大影响,那我们在软件开发的过程中,能不能利用这一点,来优化I/O 性能,提升应用程序的运行效率呢?
答案自然是肯定的。今天,我就用几个案例帮助你更好地理解缓存的作用,并学习如何充分利用这些缓存来提高程序效率。
为了方便你理解,Buffer和Cache我仍然用英文表示,避免跟"缓存"一词混淆。而文中的"缓存",通指数据在内存中的临时存储。缓存命中率
在案例开始前,你应该习惯性地先问自己一个问题,你想要做成某件事情,结果应该怎么评估?比如说,我们想利用缓存来提升程序的运行效率,应该怎么评估这个效果呢?换句话说,有没有哪个指标可以衡量缓存使用的好坏呢?
缓存命中率
在案例开始前,你应该习惯性地先问自己一个问题,你想要做成某件事情,结果应该怎么评估?比如说,我们想利用缓存来提升程序的运行效率,应该怎么评估这个效果呢?换句话说,有没有哪个指标可以衡量缓存使用的好坏呢?
我估计你已经想到了,缓存的命中率。所谓缓存命中率,是指直接通过缓存获取数据的请求次数,占所有数据请求次数的百分比。命中率越高,表示使用缓存带来的收益越高,应用程序的性能也就越好。
实际上,缓存是现在所有高并发系统必需的核心模块,主要作用就是把经常访问的数据(也就是热点数据),提前读入到内存中。这样,下次访问时就可以直接从内存读取数据,而不需要经过硬盘,从而加快应用程序的响应速度。
这些独立的缓存模块通常会提供查询接口,方便我们随时查看缓存的命中情况。不过Linux系统中并没有直接提供这些接口,所以这里我要介绍一下,cachestat 和 cachetop,它们正是查看系统缓存命中情况的工具。
- cachestat 提供了整个操作系统缓存的读写命中情况。
- cachetop 提供了每个进程的缓存命中情况。
这两个工具都是 bcc软件包的一部分,它们基于 Linux 内核的eBPF(extended Berkeley Packet Filters)机制,来跟踪内核中管理的缓存,并输出缓存的使用和命中情况。
Centos 7 cachestat 安装
# 安装bcc-tools
yum install -y bcc-tools
# 配置PATH路径
export PATH=$PATH:/usr/share/bcc/tools
# 验证安装成功
cachestat
注意:bcc-tools 需要内核版本为 4.1 或者更新的版本,如果你用的是 CentOS,那就需要手动
配置完,你就可以运行 cachestat 和 cachetop 命令了。比如,下面就是一个 cachestat 的运行界面,它以 1 秒的时间间隔,输出了 3 组缓存统计数据:
[root@docker ~]# cachestat 1 3
HITS MISSES DIRTIES HITRATIO BUFFERS_MB CACHED_MB
0 0 0 0.00% 16 394
1 0 0 100.00% 16 394
0 0 0 0.00% 16 394
你可以看到,cachestat的输出其实是一个表格。每行代表一组数据,而每一列代表不同的缓存统计指标。这些指标从左到右依次表示∶
- MSSES,表示缓存未命中的次数
- 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%
它的输出跟 top类似,默认按照缓存的命中次数(HITS)排序,展示了每个进程的缓存命中情况。具体到每一个指标,这里的HITS、MISSES和 DIRTIES,跟 cachestat 里的含义一样,分别代表间隔时间内的缓存命中次数、未命中次数以及新增到缓存中的脏页数。
而READ_HIT和WRITE_HIT,分别表示读和写的缓存命中率。
指定文件的缓存大小
Release v0.0.1 · tobert/pcstat · GitHubhttps://github.com/tobert/pcstat/releases/tag/v0.0.1
除了缓存的命中率外,还有一个指标你可能也会很感兴趣,那就是指定文件在内存中的缓存大小。你可以使用pcstat 这个工具,来查看文件在内存中的缓存大小以及缓存比例。
全部安装完成后,你就可以运行pcstat来查看文件的缓存情况了。比如,下面就是一个pcstat 运行的示例,它展示了/bin/which 这个文件的缓存情况∶
[root@docker ~]# ./pcstat /bin/which
+------------+----------------+------------+-----------+---------+
| Name | Size (bytes) | Pages | Cached | Percent |
|------------+----------------+------------+-----------+---------|
| /bin/which | 24336 | 6 | 0 | 000.000 |
+------------+----------------+------------+-----------+---------+
这个输出中,Cached就是/bin/which在缓存中的大小,而Percent 则是缓存的百分比。你看到它们都是0,这说明 /bin/which并不在缓存中。接着,如果你执行一下which命令,再运行相同的命令来查看的话,就会发现/bin/which都在缓存中了∶
[root@docker ~]# which ls
alias ls='ls --color=auto'
/usr/bin/ls
[root@docker ~]# ./pcstat /bin/which
+------------+----------------+------------+-----------+---------+
| Name | Size (bytes) | Pages | Cached | Percent |
|------------+----------------+------------+-----------+---------|
| /bin/which | 24336 | 6 | 6 | 100.000 |
+------------+----------------+------------+-----------+---------+
[root@docker ~]#
知道了缓存相应的指标和查看系统缓存的方法后,接下来,我们就进入今天的正式案例。
案例一
dd作为一个磁盘和文件的拷贝工具,经常被拿来测试磁盘或者文件系统的读写性能。不过,既然缓存会影响到性能,如果用dd 对同一个文件进行多次读取测试,测试的结果会怎么样呢?
然后,使用 dd命令生成一个临时文件,用于后面的文件读取测试∶
# 生成一个512MB的临时文件
[root@docker ~]# dd if=/dev/vdc of=file bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 4.91071 s, 109 MB/s
# 清理缓存$ echo 3 > /proc/sys/vm/drop_caches
继续在第一个终端,运行pcstat 命令,确认刚刚生成的文件不在缓存中。如果一切正常,你会看到Cached和 Percent 都是0∶
[root@docker ~]# ./pcstat file
+-------+----------------+------------+-----------+---------+
| Name | Size (bytes) | Pages | Cached | Percent |
|-------+----------------+------------+-----------+---------|
| file | 536870912 | 131072 | 0 | 000.000 |
+-------+----------------+------------+-----------+---------+
还是在第一个终端 中,现在运行cachetop命令
在第二个终端运行dd命令测试文件读写速度
[root@docker ~]# dd if=file of=/dev/null bs=1M
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 11.6797 s, 46.0 MB/s
从dd的结果可以看出,这个文件的读性能是46MB/s。由于在 dd 命令运行前我们已经清理了缓存,所以 dd 命令读取数据时,肯定要通过文件系统从磁盘中读取。不过,这是不是意味着,dd 所有的读请求都能直接发送到磁盘呢?我们再回到第一个终端,查看 cachetop界面的缓存命中情况∶
PID UID CMD HITS MISSES DIRTIES READ_HIT% WRITE_HIT%
\.\.\.
3264 root dd 37077 37330 0 49.8% 50.2%
从cachetop的结果可以发现,并不是所有的读都落到了磁盘上,事实上读请求的缓存命中率只有50%。
[root@docker ~]# ./pcstat file
+-------+----------------+------------+-----------+---------+
| Name | Size (bytes) | Pages | Cached | Percent |
|-------+----------------+------------+-----------+---------|
| file | 536870912 | 131072 | 131072 | 100.000 |
+-------+----------------+------------+-----------+---------+
接下来,我们继续尝试相同的测试命令。先切换到第二个终端,再次执行刚才的dd命令∶
[root@docker ~]# dd if=file of=/dev/null bs=1M
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 0.135962 s, 3.9 GB/s
看到这次的结果,有没有点小惊讶?磁盘的读性能居然变成了3.9GB/s,比第一次的结果明显高了太多。为什么这次的结果这么好呢?不妨再回到第一个终端,看看 cachetop的情况∶
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%
显然,cachetop也有了不小的变化。你可以发现,这次的读的缓存命中率是100.0%,也就是说这次的 dd 命令全部命中了缓存,所以才会看到那么高的性能。然后,回到第二个终端,再次执行 pcstat 查看文件 file的缓存情况∶
[root@docker ~]# ./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 的大小.
这个案例同样需要你开启两个终端。分别 SSH 登录到机器上后,先在第一个终端中运行cachetop 命令∶
接着来到第二个终端,执行下面命令运行案例
案例运行后,我们还需要运行下面这个命令,来确认案例已经正常启动。如果一切正常,你应该可以看到类似下面的输出∶
从这里你可以看到,每读取32MB的数据,就需要花0.9秒。这个时间合理吗?我想你第一反应就是,太慢了吧。那这是不是没用系统缓存导致的呢?
我们再来检查一下。回到第一个终端,先看看cachetop的输出,在这里,我们找到案例进程app的缓存使用情况∶
这个输出似乎有点意思了。1024次缓存全部命中,读的命中率是100%,看起来全部的读请求都经过了系统缓存。但是问题又来了,如果真的都是缓存I/O,读取速度不应该这么慢。不过,话说回来,我们似乎忽略了另一个重要因素,每秒实际读取的数据大小。HITS代表缓存的命中次数,那么每次命中能读取多少数据呢?自然是一页。
前面讲过,内存以页为单位进行管理,而每个页的大小是4KB。所以,在5秒的时间间隔里,命中的缓存为1024*4K/1024=4MB,再除以5秒,可以得到每秒读的缓存是0.8MB,显然跟案例应用的 32 MB/s 相差太多。至于为什么只能看到0.8MB的 HTS,我们后面再解释,这里你先知道怎么根据结果来分析就可以了。
这也进一步验证了我们的猜想,这个案例估计没有充分利用系统缓存。其实前面我们遇到过类似的问题,如果为系统调用设置直接I/O的标志,就可以绕过系统缓存。
那么,要判断应用程序是否用了直接I/O,最简单的方法当然是观察它的系统调用,查找应用程序在调用它们时的选项。使用什么工具来观察系统调用呢?自然还是 strace 继续在终端二中运行下面的 strace命令,观察案例应用的系统调用情况。注意,这里使用了pgrep命令来查找案例进程的 PID号∶
从 strace的结果可以看到,案例应用调用了openat来打开磁盘分区/dev/sdb1,并且传入的参数为O_RDONLYIO_DIRECT(中间的竖线表示或)。
O_RDONLY表示以只读方式打开,而O_DIRECT则表示以直接读取的方式打开,这会绕过系统的缓存。
验证了这一点,就很容易理解为什么读32MB的数据就都要那么久了。直接从磁盘读写的速度,自然远慢于对缓存的读写。这也是缓存存在的最大意义了。找出问题后,我们还可以在再看看案例应用的源代码,再次验证一下∶
上面的代码,很清楚地告诉我们∶它果然用了直接 I/O。
找出了磁盘读取缓慢的原因,优化磁盘读的性能自然不在话下。修改源代码,删除ODIRECT 选项,让应用程序使用缓存I/O,而不是直接 I/O,就可以加速磁盘读取速度。
app-cachedc就是修复后的源码,我也把它打包成了一个容器镜像。在第二个终端中,按Ctrl+C停止刚才的 strace命令,运行下面的命令,你就可以启动它∶
来到第二个终端,再来运行下面命令查看新应用的日志
现在,每次只需要0.03秒,就可以读取 32MB数据,明显比之前的0.9秒快多了。所以,这次应该用了系统缓存。
我们再回到第一个终端,查看 cachetop 的输出来确认一下∶
果然,读的命中率还是100%,HITS(即命中数)却变成了40960,同样的方法计算一下,换算成每秒字节数正好是32 MB(即40960*4k/5/1024=32M).
这个案例说明,在进行I/O操作时,充分利用系统缓存可以极大地提升性能。但在观察缓存命中率时,还要注意结合应用程序实际的 I/O大小,综合分析缓存的使用情况。
案例的最后,再回到开始的问题,为什么优化前,通过cachetop只能看到很少一部分数据的全部命中,而没有观察到大量数据的未命中情况呢?这是因为,cachetop 工具并不把直接I/O算进来。这也又一次说明了,了解工具原理的重要。
cachetop的计算方法涉及到/O的原理以及一些内核的知识,如果你想了解它的原理的话,可以点击这里查看它的源代码。
总结
Bufers和Cache 可以极大提升系统的I/O性能。通常,我们用缓存命中率,来衡量缓存的使用效率。命中率越高,表示缓存被利用得越充分,应用程序的性能也就越好。你可以用 cachestat和 cachetop这两个工具,观察系统和进程的缓存命中情况。
其中
● cachestat 提供了整个系统缓存的读写命中情况。
● cachetop 提供了每个进程的缓存命中情况。
不过要注意,Buffers和Cache都是操作系统来管理的,应用程序并不能直接控制这些缓存的内容和生命周期。所以,在应用程序开发中,一般要用专门的缓存组件,来进一步提升性能。比如,程序内部可以使用堆或者栈明确声明内存空间,来存储需要缓存的数据。再或者,使用Nginx Redis 这类外部缓存服务,优化数据的访问效率。