一、从读写角度看buffer 和cache的好处
二、案例：读同一文件的缓存命中情况
1、使用 dd 命令生成一个临时文件，用于后面的文件读取测试
2、 pcstat 查看缓存
3、读取文件&&cachetop 查看缓存
三、案例: 缓存对文件读的影响。
1、如何发现是否绕过系统缓存？
2、如何避免直接I/O
四、缓存命中率 && 缓存查看命令
1、cachestata
2、cachetop
3、指定文件的缓存大小
一、从读写角度看buffer 和cache的好处
Buffer 和Cache 的设计目的，是为了提升系统的 I/O 性能。它们利用内存，充当起慢速磁盘与快速CPU 之间的桥梁，可以加速 I/O 的访问速度。
Buffer 和 Cache 分别缓存的是对磁盘和文件系统的读写数据。
- 从写的角度来说，不仅可以优化磁盘和文件的写入，对应用程序也有好处，应用程序可以在数据真正落盘前，就返回去做其他工作。
- 从读的角度来说，不仅可以提高那些频繁访问数据的读取速度，也降低了频繁 I/O 对磁盘的压力
二、案例：读同一文件的缓存命中情况
dd 作为一个磁盘和文件的拷贝工具，经常被拿来测试磁盘或者文件系统的读写性能。不过，既然缓存会影响到性能，如果用 dd 对同一个文件进行多次读取测试，测试的结果会怎么样呢？
1、使用 dd 命令生成一个临时文件，用于后面的文件读取测试
生成一个 512MB 的临时文件$ dd if=/dev/sda1 of=file bs=1M count=512# 清理缓存$ echo 3 > /proc/sys/vm/drop_caches2、 pcstat 查看缓存
确认刚刚生成的文件不在缓存中。如果一切正常，你会看到 Cached 和 Percent 都是 0
pcstat file+-------+----------------+------------+-----------+---------+| Name | Size (bytes) | Pages | Cached | Percent ||-------+----------------+------------+-----------+---------|| file | 536870912 | 131072 | 0 | 000.000 |+-------+----------------+------------+-----------+---------+3、读取文件&&cachetop 查看缓存
终端1
每隔 5 秒刷新一次数据
$ cachetop 5
21:05 Buffers MB: 2 / Cached MB: 109 / Sort: HITS / Order: ascendingPID UID CMD HITS MISSES DIRTIES READ_HIT% WRITE_HIT% 12125 root dd 127305 127822 0 49.9% 50.1%读缓存 命中50%
终端2
root@ubuntu:/home/ninesun# dd if=file of=/dev/null bs=1M512+0 records in512+0 records out536870912 bytes (537 MB, 512 MiB) copied, 1.7833 s, 301 MB/s301MB/s。速度咋这么快呢？和老师的测试结果不一样? 可能是SSD的缘故吧，缓存清理了好几次测试都一样。
由于在 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%
这是什么原因呢？
看到老师的回答是: 预读
还是有些不太理解？？？？
继续尝试相同的dd 读取命令磁盘的读写一直保持在300MB/S 啥原因呢？
和老师给的例子不一样。
在老师的案例中，cachetop 的读的缓存命中率是 100.0%，也就是说这次的 dd 命令全部命中了缓存，所以才会看到那么高的性能。
pcstat 查看文件 file 的缓存
pcstat file+-------+----------------+------------+-----------+---------+| Name | Size (bytes) | Pages | Cached | Percent ||-------+----------------+------------+-----------+---------|| file | 536870912 | 131072 | 131072 | 100.000 |+-------+----------------+------------+-----------+---------+从 pcstat 的结果你可以发现，测试文件 file 已经被全部缓存了起来，这跟刚才观察到的缓存命中率 100% 是一致的。
这两次结果说明，系统缓存对第二次 dd 操作有明显的加速效果，可以大大提高文件读取的性能。
注意: dd 当成测试文件系统性能的工具，由于缓存的存在，就会导致测试结果严重失真
三、案例: 缓存对文件读的影响。
每秒从磁盘分区 /dev/sda1 中读取 32MB 的数据，并打印出读取数据花费的时间
案例场景为进程以固定间隔时间读取磁盘导致以下两种现象：
- 直接 I/O 导致文件读取缓慢的问题
- 缓存命中次数与 I/O 大小不匹配的问题
shell1
cachetop 5shell2
docker run --privileged --name=app -itd feisky/app:io-direct /app -d /dev/sdb -s 33554432 -itd -t ：指定要创建的目标镜像名；-i: 交互式操作；-d 设置要读取的磁盘，默认前缀为 /dev/sd 或者 /dev/xvd 的磁盘-s 设置每次读取的数据量大小，单位为字节，默认为 33554432(也就是 32MB) root@ubuntu:/home/wx# docker run --privileged --name=app -itd feisky/app:io-directUnable to find image 'feisky/app:io-direct' locallyio-direct: Pulling from feisky/app32802c0cfa4d: Pull complete da1315cffa03: Pull complete fa83472a3562: Pull complete f85999a86bef: Pull complete e450b6f99bbe: Pull complete a374aef23781: Pull complete Digest: sha256:76bbf2b6356c73a133cba26792827216bf1d9661e6050f6a29c9f17d943bd3c2Status: Downloaded newer image for feisky/app:io-direct6fdb4b4ff82322cceda29a69aab5e57bfe4465f373665e3b07e286b582b00fc7 查看耗费时间
root@ubuntu:/home/wx# docker logs appReading data from disk /dev/sda1 with buffer size 33554432Time used: 0.034711 s to read 33554432 bytesTime used: 0.021213 s to read 33554432 bytesTime used: 0.022117 s to read 33554432 bytesTime used: 0.021257 s to read 33554432 bytesTime used: 0.022507 s to read 33554432 bytesTime used: 0.021167 s to read 33554432 bytesTime used: 0.028163 s to read 33554432 bytes每读取 32 MB 的数据，就需要花 0.9 秒，这个速度显然太慢了。
老师的cachetop的结果
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，读取速度不应该这么慢。
我的cachetop结果
注意：
- cachetop 工具并不是直接 I/O 算进来
- hits 的次数是1024，单位是页。 page大小是4 *1024Kb =4096KB=4MB 。
cachetop 每5秒刷新一次 4MB /5s 大约是0.8MB。
缓存命中次数与 I/O 大小不匹配的，显然没有充分利用缓存，
1、如何发现是否绕过系统缓存？
要判断应用程序是否用了直接 I/O，观察它的系统调用，查找应用程序在调用它们时的选项
root@ubuntu:/home/wx# strace -p $(pgrep app)strace: Process 14369 attachedrestart_syscall(<... resuming interrupted nanosleep ...>) = 0openat(AT_FDCWD, "/dev/sda1", O_RDONLY|O_DIRECT) = 4mmap(NULL, 33558528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5cca94e000read(4, "00000000000000000000000000000000"..., 33554432) = 33554432write(1, "Time used: 0.026830 s to read 33"..., 45) = 45close(4) = 0munmap(0x7f5cca94e000, 33558528) = 0nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffe65fd76b0) = 0openat(AT_FDCWD, "/dev/sda1", O_RDONLY|O_DIRECT) = 4mmap(NULL, 33558528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5cca94e000read(4, "00000000000000000000000000000000"..., 33554432) = 33554432write(1, "Time used: 0.021222 s to read 33"..., 45) = 45close(4) = 0openat(AT_FDCWD, "/dev/sda1", O_RDONLY|O_DIRECT) = 4
openat 来打开磁盘分区 /dev/sda1，并且传入的参数为 O_RDONLY|O_DIRECT(中间的竖线表示或)
O_RDONLY 表示以只读方式打开，而 O_DIRECT 则表示以直接读取的方式打开，这会绕过系统的缓存
从结果看到是读请求直接打到磁盘了，这也可以看出磁盘和内存的速度差异是很大的。
本地的环境是虚拟机且宿主机的硬盘是环境是SSD，直接读取的速度也很快的。
2、如何避免直接I/O
删除O_DIRECT 选项，让应用程序使用缓存 I/O ，而不是直接 I/O
int flags = O_RDONLY | O_LARGEFILE | O_DIRECT;int fd = open(disk, flags, 0755);if (fd < 0){perror("failed to open disk");_exit(1);}删除后重新运行
# 删除上述案例应用root@ubuntu:/home/wx# docker rm -f appapp# 运行修复后的应用$ docker run --privileged --name=app -itd feisky/app:io-cached root@ubuntu:/home/wx/linux-perf-examples/io-cached# docker run --privileged --name=app -itd feisky/app:io-cached487fb08e3d190107cff745d0ee0f622d70bb89ba41959f763ed622550f83afc1 该容器第一次已经被构建了，第二使用该容器只会打印出容器id查看日志
root@ubuntu:/home/wx# docker logs appReading data from disk /dev/sda1 with buffer size 33554432Time used: 0.033302 s to read 33554432 bytesTime used: 0.018244 s to read 33554432 bytesTime used: 0.032391 s to read 33554432 bytesTime used: 0.022899 s to read 33554432 bytesTime used: 0.025170 s to read 33554432 bytesTime used: 0.024780 s to read 33554432 bytes每次只需要 0.03 秒，就可以读取 32MB 数据，明显比之前的 0.9 秒快多了。所以，这次应该用了系统缓存
已经没有了O_DIRECT 则表示以直接读取这个参数。
root@ubuntu:/home/wx/linux-perf-examples/io-cached# strace -p $(pgrep app)strace: Process 16054 attachedrestart_syscall(<... resuming interrupted clock_nanosleep ...>) = 0openat(AT_FDCWD, "/dev/sda1", O_RDONLY) = 4mmap(NULL, 33558528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff8f90a0000read(4, "00000000000000000000000000000000"..., 33554432) = 33554432write(1, "Time used: 0.023739 s to read 33"..., 45) = 45close(4) = 0munmap(0x7ff8f90a0000, 33558528) = 0clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, 0x7fff275a0160) = 0openat(AT_FDCWD, "/dev/sda1", O_RDONLY) = 4查看 cachetop 的输出
读的命中率还是 100%，HITS (即命中数)却变成了 40960(对于我的环境不管是否直接I/O还是走系统缓存都是一样的)，同样的方法计算一下，换算成每秒字节数正好是 32 MB(即 40960*4k/5/1024=32M)。
四、缓存命中率 && 缓存查看命令
什么是缓存命中率？
直接通过缓存获取数据的请求次数，占所有数据请求次数的百分比
命中率越高，表示使用缓存带来的收益越高，应用程序的性能也就越好
缓存是现在所有高并发系统必需的核心模块，主要作用就是把经常访问的数据(也就是热点数据)，提前读入到内存中。这样，下次访问时就可以直接从内存读取数据，而不需要经过硬盘，从而加快应用程序的响应速度。这些独立的缓存模块通常会提供查询接口，方便我们随时查看缓存的命中情况。不过Linux 系统中并没有直接提供这些接口，所以这里我要介绍一下，cachestat 和 cachetop，它们正是查看系统缓存命中情况的工具。
这两个工具都是 bcc 软件包的一部分，它们基于 Linux 内核的 eBPF(extendedBerkeley Packet Filters)机制，来跟踪内核中管理的缓存，并输出缓存的使用和命中情况。
- cachestat 提供了整个操作系统缓存的读写命中情况。
- cachetop 提供了每个进程的缓存命中情况
在 Ubuntu 系统中，你可以运行下面的命令来安装：
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 4052245BD4284CDDecho "deb https://repo.iovisor.org/apt/xenial xenial main" | sudo tee /etc/apt/sources.lsudo apt-get updatesudo apt-get install -y bcc-tools libbcc-examples linux-headers-$(uname -r)CentOS需要升级内核到4.1 或更新的版本。
加载环境变量
export PATH=$PATH:/usr/share/bcc/tools1、cachestata
root@ubuntu:/opt# cachestat 1 3 HITS MISSES DIRTIES HITRATIO BUFFERS_MB CACHED_MB 0 1152 0 0.00% 0 64 0 422 0 0.00% 0 65 0 40 0 0.00% 0 67MISSES ，表示缓存未命中的次数；
HITS ，表示缓存命中的次数；
DIRTIES， 表示新增到缓存中的脏页数；
BUFFERS_MB 表示 Buffers 的大小，以 MB 为单位；
CACHED_MB 表示 Cache 的大小，以 MB 为单位
2、cachetop
06:21:44 Buffers MB: 2 / Cached MB: 74 / Sort: HITS / Order: ascendingPID UID CMD HITS MISSES DIRTIES READ_HIT% WRITE_HIT% 1 root systemd 0 267 0 0.0% 100.0% 1599 ninesun Xorg 0 117 0 0.0% 100.0% 1605 ninesun InputThread 0 126 0 0.0% 100.0% 1725 ninesun dbus-daemon 0 57 0 0.0% 100.0% 1728 ninesun at-spi2-registr 0 154 0 0.0% 100.0% 1743 ninesun gnome-shell 0 3956 0 0.0% 100.0% 1762 ninesun gdbus 0 32 0 0.0% 100.0% 2081 ninesun gnome-terminal- 0 1017 0 0.0% 100.0% 2083 ninesun gdbus 0 59 0 0.0% 100.0% 422 root systemd-udevd 0 100 0 0.0% 100.0% 539 systemd- systemd-resolve 0 55 0 0.0% 100.0% 656 root wpa_supplicant 0 59 0 0.0% 100.0% 6573 root containerd 0 532 0 0.0% 100.0% 6586 root containerd 0 109 0 0.0% 100.0% 661 root gmain 1 1 0 50.0% 50.0% 699 root gmain 8 1 0 88.9% 11.1% 1117 root vmtoolsd 11 515 0 2.1% 97.9% 2112 ninesun gmain 19 4 0 82.6% 17.4% 4437 root gmain 36 26 0 58.1% 41.9% 1939 ninesun vmtoolsd 37 381 0 8.9% 91.1% 2131 root gmain 39 19 0 67.2% 32.8% 541 systemd- systemd-timesyn 107 139 0 43.5% 56.5% 2114 ninesun gmain 137 109 0 55.7% 44.3% 1484 gdm gsd-color 144 232 0 38.3% 61.7% 12629 root cachetop 272 1284 0 17.5% 82.5% 12347 root unattended-upgr 1536 7487 0 17.0% 83.0% HITS、MISSES 和 DIRTIES ，跟 cachestat 里的含义一样，分别代表间隔时间内的缓存命中次数、未命中次数以及新增到缓存中的脏页数
READ_HIT 和 WRITE_HIT ，分别表示读和写的缓存命中率
3、指定文件的缓存大小
pcstat 查看文件在内存中的缓存大小以及缓存比例。
pcstat 是一个基于 Go 语言开发的工具，所以安装它之前，你首先应该安装 Go 语言。
go环境搭建完后，安装pcstat
export GOPATH=~/goexport PATH=~/go/bin:$PATH go get golang.org/x/sys/unix/bin/ls 文件的缓存情况
pcstat /bin/ls+---------+----------------+------------+-----------+---------+| Name | Size (bytes) | Pages | Cached | Percent ||---------+----------------+------------+-----------+---------|| /bin/ls | 133792 | 33 | 0 | 000.000 |+---------+----------------+------------+-----------+---------+
扫一扫
1923
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
