其他分享
首页 > 其他分享> > (案例7)未利用系统缓存导致 I/O 缓慢

(案例7)未利用系统缓存导致 I/O 缓慢

作者:互联网

前提

前面有学到 Buffer 和 Cache 的概念:https://www.cnblogs.com/poloyy/p/13503848.html

我们来简单复习下

 

Buffer 和 Cache 的设计目的

为了提升系统的 I/O 性能,它们利用内存,充当起慢速磁盘和快速 CPU 之间的桥梁,可以加速 I/O 的访问速度

 

Buffer 和 Cache

 

读写角度

 

引入主题

既然 Buffer 和 Cache 对系统性能有很大影响,那我们在软件开发的过程中,能不能利用这 一点,来优化 I/O 性能,提升应用程序的运行效率呢? 答案自然是肯定的

 

缓存命中率

灵魂拷问

我们想利用缓存来提升程序的运行效率,应该怎么评估这个效果呢?换句话说,有没有哪个指标可以衡量缓存使用的好坏呢?

 

灵魂回答

 

缓存的重要性

 

cachestat、cachetop

独立的缓存模块通常会提供查询接口,方便我们随时查看缓存的命中情况

不过 Linux 系统中并没有直接提供这些接口,所以这里要介绍一下,cachestat 和 cachetop ,它们正是查看系统缓存命中情况的工具

 

Ubuntu 安装工具

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)

 

配置环境变量

vim /etc/profile # 在文件结尾处添加 export PATH=$PATH:/usr/share/bcc/tools # 保存文件后 source /etc/profile

 

cachestat

# 它以 1 秒的时间间隔,输出了 3 组缓存统计数据 cachestat 1 3

字段说明

 

cachetop

cachetop

 

查看文件的缓存大小

可以使用 pcstat 这个工具,来查看文件在内存中的缓存大小以及缓存比例

 

安装 pcstat

# 安装 go apt install golang-go vim /etc/profile # 在文件结尾处添加 export GOPATH=~/go export PATH=~/go/bin:$PATH # 保存文件后 source /etc/profile go get golang.org/x/sys/unix go get github.com/tobert/pcstat/pcstat

 

运行 pcstat

pcstat /bin/ls

Cached 就是 /bin/ls 在缓存中的大小,而 Percent 则是缓存的百分比,看到它们都是 0,这说明 /bin/ls 并不在缓存中

 

执行 ls 命令,再来查看

ls pcstat /bin/ls

发现都在缓存中了

 

讲案例前的准备

 

案例一:通过 dd 写入读取文件

注意:没说第几个终端都是默认第一个终端执行命令哦

 

 dd 命令生成一个临时文件

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

 

运行 pcstat 查看 file 文件

pcstat file

确认刚刚生成的文件不在缓存中。如果一切正常, 会看到 Cached 和 Percent 都是 0

 

运行 cachetop 

# 每隔 1 秒刷新一次数据 cachetop 1

 

第二个终端运行 dd 命令

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

 

查看 cachetop

可以看到 dd 命令并不是所有的读都落到了磁盘上,读请求的缓存命中率只有 50%

 

第二个终端再次运行 dd 命令

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

磁盘的读性能蹭蹭蹭往上涨,去到了 1.6GB/s

 

再查看 cachetop

可以发现,这次读的缓存命中率是 100%

 

第二个终端运行 pcstat

pcstat file

测试文件已经被全部缓存起来了,和刚刚 cachetop 观察到缓存命中率 100% 是一致的

 

总结

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

 

案例二

前提

 

查看应用日志

从这里可以看到,每读取 32 MB 的数据,就需要花 0.9 秒

 

灵魂拷问

这个时间合理吗?这也太慢了吧,那这是不是没用系统缓存导致的呢?

 

查看 cachetop

结果分析

读的命中率虽然是 100%,命中次数是 1024,看起来全部的读请求都经过了系统缓存

 

灵魂又拷问了

全都是缓存 I/O,读取速度不应该这么慢

 

深入分析

 

结果猜想

这个案例估计没有充分利用系统缓存,如果系统调用设置直接 I/O 的标志,就可以绕过系统缓存

 

通过 strace 观察系统调用

strace -p $(pgrep app)

结果分析

 

查看应用源码

它果然用了直接 I/O

 

修改源代码

删除 O_DIRECT 选项,让应用程序使用缓存 I/O ,而不是直接 I/O,就可以加速磁盘读取速度

 

验证修复后的应用

查看新应用的日志

结果分析

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

 

再次查看 cachetop

结果分析

 

总结

 

扩展

为什么优化前,通过 cachetop 只能看到很少一部分数据的全部命中,而没有观察到大量数据的未命中情况呢?

 

回答

是因为,cachetop 工具并不把直接 I/O 算进来

标签:缓存,读取,cachetop,dd,pcstat,案例,命中,缓慢
来源: https://www.cnblogs.com/uestc2007/p/14677791.html