illx10000

• 3. 度量与工具
  • 3.1 机器提供的能力
  • 3.2 程序预计消耗的性能
  • 3.3 程序实际消耗的性能
    • 3.3.1 系统级别监控 iostat
    • 3.3.2 进程IO使用度量
    • 3.3.3 程序内调用：

3. 度量与工具

接上文，我们讲 熟知

• 机器能够提供的能力
• 程序预期消耗的性能
• 程序实际消耗的性能
  是必不可缺的。

3.1 机器提供的能力

因为所有的程序都是部署在机器上，所以需要了解机器提供的能力，选择合适的机器类型很重要，例如

• 在接入层通常需要网卡性能较好，内存较高，备用电源等服务器，通常不需要硬盘性能很好
• 在业务逻辑层（非cache类服务），通常需要CPU核数适当，磁盘容量不需要太大的服务器，还有现在比较火的K8S的容器等
• 存储类服务（热存储），例如DB，通常需要磁盘性能较好，有RAID，或者SSD服务器
• 存储类服务（冷存储），类如脚本机，冷备份机器，通常是固态硬盘较大

根据业务的形态，再选择合适类型的机器

3.2 程序预计消耗的性能

预估程序消耗的性能，通常有两种方式：

• 白核，理论上预估：从业务逻辑出发，从代码出发，预估需要消耗的资源。个人觉得主要思路是：
  • 评估代码，找寻短板：例如程序大量读写文件，那么应该需要考虑磁盘压力，如果使用大量内容，需要考虑内存压力，大量复杂计算，则需要考虑CPU的计算性能。
  • 了解常见的耗时，容量评估方式：https://zhuanlan.zhihu.com/p/99837672
• 黑核，压力测试：直接对需要评估的函数/服务进行压力测试，得到在制定机器上具体的数字

通常上面两种方式会结合使用，通过代码评估可能的性能短板在哪里，通过压力测试来评估真正的性能数据

3.3 程序实际消耗的性能

回到主题，如何了解程序消耗的磁盘性能，换句话说 如何对 Linux IO 进行监控与深入分析？ 以下内容主要参考这篇文章：

• Linux IO 监控与深入分析
• Linux iostat 命令

如果能够回答下面三个问题，那么问题也就解决了很大一半，剩下的问题可能依然需要具体分析：

• 当前服务器是否有IO问题？
• 如果有IO问题，可能是哪些程序导致的？
• 这些程序是怎么导致的IO问题？

3.3.1 系统级别监控 iostat

iostat 主要用于监控系统设备的 IO 负载情况，iostat 首次运行时显示自系统启动开始的各项统计信息，之后运行 iostat 将显示自上次运行该命令以后的统计信息。 iostat 的特点是汇报磁盘活动统计情况，同时也会汇报出 CPU 使用情况。CPU 统计数据是作为所有处理器之间的平均值在系统范围内计算的。iostat 也有一个弱点，就是它不能对某个进程进行深入分析，仅对系统的整体情况进行分析。

通过下面的命令，可以连续输出磁盘IO的信息

iostat -xdm 1

输出可以自己执行一下看一下，大致如下图：

Linux 4.15.0-142-generic (VM-16-4-ubuntu)       11/03/2021      _x86_64_        (1 CPU)

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
loop0             0.00     0.00    0.00    0.00     0.00     0.00    51.46     0.00    0.50    0.50    0.00   0.08   0.00
scd0              0.00     0.00    0.00    0.00     0.00     0.00    80.89     0.00    0.24    0.24    0.00   0.18   0.00
vda               0.00     1.78   88.40    1.01     5.81     0.02   133.38     0.05    1.15    1.13    2.57   0.60   5.37

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
loop0             0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
scd0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vda               0.00     2.06 2648.45    8.25    93.84     0.04    72.37     5.11    2.30    2.30    4.00   0.31  81.65

man 一下 iostat可以得到下面的解释

• rrqm/s : The number of read requests merged per second that were queued to the device. 排队到设备时，每秒合并的读请求数量

• wrqm/s : The number of write requests merged per second that were queued to the device. 排队到设备时，每秒合并的写请求数量

• r/s The number of read requests that were issued to the device per second. 每秒发送给设备的读请求数量

• w/s The number of write requests that were issued to the device per second. 每秒发送给设备的的写请求数量

• rMB/s The number of megabytes read from the device per second. 每秒从设备中读取多少 MBs

• wMB/s The number of megabytes written to the device per second. 每秒往设备中写入多少 MBs

• avgrq-sz: The average size (in sectors) of the requests that were issued to the device. 分发给设备的请求的平均大小（以扇区为单位） 磁盘扇区是磁盘的物理属性，它是磁盘设备寻址的最小单元，磁盘扇区大小可以用 fdisk -l 命令查看 另外，常说的“块”（Block）是文件系统的抽象，不是磁盘本身的属性。 另外一种说明： 提交给驱动层的 IO 请求大小，一般不小于 4K，不大于 max(readahead_kb, max_sectors_kb) 可用于判断当前的 IO 模式，一般情况下，尤其是磁盘繁忙时，越大代表顺序，越小代表随机

• avgqu-sz: The average queue length of the requests that were issued to the device. 分发给设备的请求的平均队列长度

• await: The average time (in milliseconds) for I/O requests issued to the device to be served. This includes the time spent by the requests in queue and the time spent servicing them. 分发给设备的 I/O 请求的平均响应时间（单位是毫秒） 这个时间包含了花在请求在队列中的时间和服务于请求的时间 另外一种说明： 每一个 I/O 请求的处理的平均时间（单位是毫秒）。这里可以理解为 I/O 的响应时间。 一般地，系统 I/O 响应时间应该低于 5ms，如果大于 10ms 就比较大了。

• svctm The average service time (in milliseconds) for I/O requests that were issued to the device. Warning! Do not trust this field any more. This field will be removed in a future sysstat version. 分发给设备的 I/O 请求的平均服务时间。（单位是毫秒） 警告！不要再相信这列值了。这一列将会在一个将来的 sysstat 版本中移除。 另外一种说明： 一次 IO 请求的服务时间，对于单块盘，完全随机读时，基本在 7ms 左右，即寻道 + 旋转延迟时间

• %util Percentage of elapsed time during which I/O requests were issued to the device (bandwidth utilization for the device). Device saturation occurs when this value is close to 100%. 分发给设备的 I/O 请求的运行时间所占的百分比。（设备的带宽利用率） 设备饱和会发生在这个值接近 100%。 另外一种说明： 代表磁盘繁忙程度。100% 表示磁盘繁忙，0% 表示磁盘空闲。但是注意，磁盘繁忙不代表磁盘(带宽)利用率高。 在统计时间内所有处理 I/O 时间，除以总共统计时间。 例如，如果统计间隔 1 秒，该设备有 0.8 秒在处理 I/O，而 0.2 秒闲置，那么该设备的 %util = 0.8/1 = 80%， 所以该参数暗示了设备的繁忙程度。一般地，如果该参数是 100% 表示设备已经接近满负荷运行了 （当然如果是多磁盘，即使 %util 是 100%，因为磁盘的并发能力，所以磁盘使用未必就到了瓶颈）。

• %iowait Show the percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request. 显示当系统有一个显著的磁盘 I/O 请求期间，CPU 空闲时间的百分比。

总结：

• 如果 %iowait 的值过高，表示磁盘存在 I/O 瓶颈。
• 如果 %util 接近 100%，说明产生的 I/O 请求太多，I/O 系统已经满负荷，该磁盘可能存在瓶颈。
• 如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；
• 如果 await 远大于 svctm，说明 I/O 队列太长，I/O 响应太慢，则需要进行必要优化。
• 如果 avgqu-sz 比较大，也表示有大量 IO 在等待。

3.3.2 进程IO使用度量

通常使用

• iotop：类似于top，先看整体消耗
• pidstat：再看个别进程的消耗

3.3.3 程序内调用：

通常使用

• 可以使用lsof 查看进程读取的文件列表
• strace看文件调用过程

This site is open source. Improve this page.