十七、Linux性能优化实战学习笔记-如何利用系统缓存优化程序的运行效率?

简介: Buffer 和Cache 的设计目的,是为了提升系统的 I/O 性能。它们利用内存,充当起慢速磁盘与快速CPU 之间的桥梁,可以加速 I/O 的访问速度。

一、从读写角度看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_caches

2、 pcstat 查看缓存

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

pcstat file
+-------+----------------+------------+-----------+---------+
| Name | Size (bytes) | Pages | Cached | Percent |
|-------+----------------+------------+-----------+---------|
| file | 536870912 | 131072 | 0 | 000.000 |
+-------+----------------+------------+-----------+---------+

3、读取文件&&cachetop 查看缓存

终端1


每隔 5 秒刷新一次数据

$ cachetop 5


2

21:05 Buffers MB: 2 / Cached MB: 109 / Sort: HITS / Order: ascending
PID      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=1M
512+0 records in
512+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 1.7833 s, 301 MB/s

301MB/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 操作有明显的加速效果,可以大大提高文件读取的性能。<对SSD 也是如此吗?>


注意: dd 当成测试文件系统性能的工具,由于缓存的存在,就会导致测试结果严重失真

三、案例: 缓存对文件读的影响。

每秒从磁盘分区 /dev/sda1 中读取 32MB 的数据,并打印出读取数据花费的时间


案例场景为进程以固定间隔时间读取磁盘导致以下两种现象:

  • 直接 I/O 导致文件读取缓慢的问题
  • 缓存命中次数与 I/O 大小不匹配的问题

shell1

cachetop 5

shell2

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-direct
Unable to find image 'feisky/app:io-direct' locally
io-direct: Pulling from feisky/app
32802c0cfa4d: Pull complete 
da1315cffa03: Pull complete 
fa83472a3562: Pull complete 
f85999a86bef: Pull complete 
e450b6f99bbe: Pull complete 
a374aef23781: Pull complete 
Digest: sha256:76bbf2b6356c73a133cba26792827216bf1d9661e6050f6a29c9f17d943bd3c2
Status: Downloaded newer image for feisky/app:io-direct
6fdb4b4ff82322cceda29a69aab5e57bfe4465f373665e3b07e286b582b00fc7


查看耗费时间

root@ubuntu:/home/wx# docker logs app
Reading data from disk /dev/sda1 with buffer size 33554432
Time used: 0.034711 s to read 33554432 bytes
Time used: 0.021213 s to read 33554432 bytes
Time used: 0.022117 s to read 33554432 bytes
Time used: 0.021257 s to read 33554432 bytes
Time used: 0.022507 s to read 33554432 bytes
Time used: 0.021167 s to read 33554432 bytes
Time 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: ascending
PID UID CMD HITS MISSES DIRTIES READ_HIT% WRITE_HIT%
21881 root app 1024 0 0 100.0% 0.0%

1024 次缓存全部命中,读的命中率是 100%,看起来全部的读请求都经过了系统缓存。但是问题又来了,如果真的都是缓存 I/O,读取速度不应该这么慢。


我的cachetop结果

20200820173608602.png

注意:

  • 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 attached
restart_syscall(<... resuming interrupted nanosleep ...>) = 0
openat(AT_FDCWD, "/dev/sda1", O_RDONLY|O_DIRECT) = 4
mmap(NULL, 33558528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5cca94e000
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 33554432) = 33554432
write(1, "Time used: 0.026830 s to read 33"..., 45) = 45
close(4)                                = 0
munmap(0x7f5cca94e000, 33558528)        = 0
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffe65fd76b0) = 0
openat(AT_FDCWD, "/dev/sda1", O_RDONLY|O_DIRECT) = 4
mmap(NULL, 33558528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5cca94e000
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 33554432) = 33554432
write(1, "Time used: 0.021222 s to read 33"..., 45) = 45
close(4)                                = 0

openat(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 app
app
# 运行修复后的应用
$ 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-cached
487fb08e3d190107cff745d0ee0f622d70bb89ba41959f763ed622550f83afc1
该容器第一次已经被构建了,第二使用该容器只会打印出容器id

查看日志

root@ubuntu:/home/wx# docker logs app
Reading data from disk /dev/sda1 with buffer size 33554432
Time used: 0.033302 s to read 33554432 bytes
Time used: 0.018244 s to read 33554432 bytes
Time used: 0.032391 s to read 33554432 bytes
Time used: 0.022899 s to read 33554432 bytes
Time used: 0.025170 s to read 33554432 bytes
Time 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 attached
restart_syscall(<... resuming interrupted clock_nanosleep ...>) = 0
openat(AT_FDCWD, "/dev/sda1", O_RDONLY) = 4
mmap(NULL, 33558528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff8f90a0000
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 33554432) = 33554432
write(1, "Time used: 0.023739 s to read 33"..., 45) = 45
close(4)                                = 0
munmap(0x7ff8f90a0000, 33558528)        = 0
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, 0x7fff275a0160) = 0
openat(AT_FDCWD, "/dev/sda1", O_RDONLY) = 4

查看 cachetop 的输出

20200820172911647.png

读的命中率还是 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 4052245BD4284CDD
echo "deb https://repo.iovisor.org/apt/xenial xenial main" | sudo tee /etc/apt/sources.l
sudo apt-get update
sudo apt-get install -y bcc-tools libbcc-examples linux-headers-$(uname -r)

CentOS需要升级内核到4.1 或更新的版本。


加载环境变量

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

1、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         67

MISSES ,表示缓存未命中的次数;

HITS ,表示缓存命中的次数;

DIRTIES, 表示新增到缓存中的脏页数

BUFFERS_MB 表示 Buffers 的大小,以 MB 为单位;

CACHED_MB 表示 Cache 的大小,以 MB 为单位

2、cachetop

06:21:44 Buffers MB: 2 / Cached MB: 74 / Sort: HITS / Order: ascending
PID      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=~/go
export 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 |
+---------+----------------+------------+-----------+---------+
相关实践学习
CentOS 7迁移Anolis OS 7
龙蜥操作系统Anolis OS的体验。Anolis OS 7生态上和依赖管理上保持跟CentOS 7.x兼容,一键式迁移脚本centos2anolis.py。本文为您介绍如何通过AOMS迁移工具实现CentOS 7.x到Anolis OS 7的迁移。
目录
相关文章
|
19天前
|
消息中间件 缓存 NoSQL
Redis 是一个高性能的键值对存储系统,常用于缓存、消息队列和会话管理等场景。
【10月更文挑战第4天】Redis 是一个高性能的键值对存储系统,常用于缓存、消息队列和会话管理等场景。随着数据增长,有时需要将 Redis 数据导出以进行分析、备份或迁移。本文详细介绍几种导出方法:1)使用 Redis 命令与重定向;2)利用 Redis 的 RDB 和 AOF 持久化功能;3)借助第三方工具如 `redis-dump`。每种方法均附有示例代码,帮助你轻松完成数据导出任务。无论数据量大小,总有一款适合你。
55 6
|
1天前
|
缓存 Java Shell
Android 系统缓存扫描与清理方法分析
Android 系统缓存从原理探索到实现。
26 15
Android 系统缓存扫描与清理方法分析
|
11天前
|
机器学习/深度学习 人工智能 Ubuntu
|
23天前
|
存储 数据可视化 Java
震惊!如何在linux下部署项目,部署/运行jar包 超详细保姆级教程!
如何在Linux系统下部署和运行Java项目jar包,包括传输文件到Linux、使用nohup命令运行jar包、查看端口状态、杀死进程和查看项目运行状态,以及如何解决“没有主清单属性”的错误。
161 1
震惊!如何在linux下部署项目,部署/运行jar包 超详细保姆级教程!
|
13天前
|
运维 Java Linux
【运维基础知识】Linux服务器下手写启停Java程序脚本start.sh stop.sh及详细说明
### 启动Java程序脚本 `start.sh` 此脚本用于启动一个Java程序,设置JVM字符集为GBK,最大堆内存为3000M,并将程序的日志输出到`output.log`文件中,同时在后台运行。 ### 停止Java程序脚本 `stop.sh` 此脚本用于停止指定名称的服务(如`QuoteServer`),通过查找并终止该服务的Java进程,输出操作结果以确认是否成功。
20 1
|
15天前
|
存储 缓存 固态存储
|
2月前
|
消息中间件 分布式计算 Java
Linux环境下 java程序提交spark任务到Yarn报错
Linux环境下 java程序提交spark任务到Yarn报错
36 5
|
2月前
|
Linux Shell
6-9|linux查询现在运行的进程
6-9|linux查询现在运行的进程
|
2月前
|
缓存 运维 NoSQL
二级缓存架构极致提升系统性能
本文详细阐述了如何通过二级缓存架构设计提升高并发下的系统性能。
111 12
|
2月前
|
存储 传感器 Linux
STM32微控制器为何不适合运行Linux系统的分析
总的来说,虽然技术上可能存在某些特殊情况下将Linux移植到高端STM32微控制器上的可能性,但从资源、性能、成本和应用场景等多个方面考虑,STM32微控制器不适合运行Linux系统。对于需要运行Linux的应用,更适合选择ARM Cortex-A系列处理器的开发平台。
187 0