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 # 验证安装成功
转载于:https://www.cnblogs.com/qccz123456/p/11171997.html
- 点赞
- 收藏
- 分享
- 文章举报
- Linux性能优化从入门到实战:13 内存篇:内存指标/工具总结、问题定位和调优...
- Linux性能优化从入门到实战:12 内存篇:Swap 基础
- Linux性能优化从入门到实战:11 内存篇:内存泄漏的发现与定位
- 一个优秀的Java程序员必须了解GC的工作原理、如何优化GC的性能、如何与GC进行有限的交互,有一些应用程序对性能要求较高,例如嵌入式系统、实时系统等,只有全面提升内存的管理效率,才能提高整个应用程序
- C# ASP.NET 优化程序性能、降低内存使用、提高程序运行速度
- 在 Linux 上如何清除内存的 Cache、Buffer 和交换空间
- Linux性能优化从入门到实战:02 CPU篇:平均负载
- Linux性能优化从入门到实战:15 文件系统篇:磁盘 I/O
- Unix/Linux环境C编程入门教程(22) C/C++如何获取程序的运行时间
- 10—(优化处理)详细剖析Android Traceview 效率检视工具!分析程序运行速度!并讲解两种创建SDcard方式!
- [C/C++]_[初级]_[如何编写简单有效代码,提高程序运行效率和性能]
- Linux性能优化从入门到实战:05 CPU篇:硬中断、软中断
- Linux性能优化从入门到实战:14 文件系统篇:Linux 文件系统基础
- 如何利用VS的代码优化和openmp并行计算提高程序运行速度
- 在 Linux 上如何清除内存的 Cache、Buffer 和交换空间
- 如何理解Android程序运行性能优化
- 在 Linux 上如何清除内存的 Cache、Buffer 和交换空间
- 在 Linux 上如何清除内存的 Cache、Buffer 和交换空间
- Linux性能优化从入门到实战:03 CPU篇:CPU上下文切换
- Linux性能优化从入门到实战:06 CPU篇:快速定位CPU瓶颈