10磁盘调优

评估 I/O 模式和调度算法

磁盘

根据存储介质的不同，常见磁盘可以分为两类：机械磁盘和固态磁盘。

机械磁盘，也称为硬盘驱动器（Hard Disk Driver），通常缩写为** HDD**。机械磁盘主要由盘片和读写磁头组成，数据就存储在盘片的环状磁道中。在读写数据前，需要移动读写磁头，定位到数据所在的磁道，然后才能访问数据。

显然，如果 I/O 请求刚好连续，那就不需要磁道寻址，自然可以获得最佳性能。这其实就是我们熟悉的，连续 I/O 的工作原理。与之相对应的，当然就是随机 I/O，它需要不停地移动磁头，来定位数据位置，所以读写速度就会比较慢。

固态磁盘（Solid State Disk），通常缩写为 SSD，由固态电子元器件组成。固态磁盘不需要磁道寻址，所以，不管是连续 I/O，还是随机 I/O 的性能，都比机械磁盘要好得多。

其实，无论机械磁盘，还是固态磁盘，相同磁盘的随机 I/O 都要比连续 I/O 慢很多，原因也很明显。

对机械磁盘来说，我们刚刚提到过的，由于随机 I/O 需要更多的磁头寻道和盘片旋转，它的性能自然要比连续 I/O 慢。
而对固态磁盘来说，虽然它的随机性能比机械硬盘好很多，但同样存在“先擦除再写入”的限制。随机读写会导致大量的垃圾回收，所以相对应的，随机 I/O 的性能比起连续 I/O 来，也还是差了很多。
此外，连续 I/O 还可以通过预读的方式，来减少 I/O 请求的次数，这也是其性能优异的一个原因。很多性能优化的方案，也都会从这个角度出发，来优化 I/O 性能。

此外，机械磁盘和固态磁盘还分别有一个最小的读写单位。

机械磁盘的最小读写单位是扇区，一般大小为 512 字节。
而固态磁盘的最小读写单位是页，通常大小是 4KB、8KB 等。

如果每次都读写 512 字节这么小的单位的话，效率很低。所以，文件系统会把连续的扇区或页，组成逻辑块，然后以逻辑块作为最小单元来管理数据。常见的逻辑块的大小是 4KB，也就是说，连续 8 个扇区，或者单独的一个页，都可以组成一个逻辑块。

除了可以按照存储介质来分类，另一个常见的分类方法，是按照接口来分类，比如可以把硬盘分为

IDE（Integrated Drive Electronics）
SCSI（Small Computer System Interface）
SAS（Serial Attached SCSI）
SATA（Serial ATA）
FC（Fibre Channel）等

不同的接口，往往分配不同的设备名称。比如， IDE 设备会分配一个 hd 前缀的设备名，SCSI 和 SATA 设备会分配一个 sd 前缀的设备名。如果是多块同类型的磁盘，就会按照 a、b、c 等的字母顺序来编号。

除了磁盘本身的分类外，当你把磁盘接入服务器后，按照不同的使用方式，又可以把它们划分为多种不同的架构。

最简单的，就是直接作为独立磁盘设备来使用。这些磁盘，往往还会根据需要，划分为不同的逻辑分区，每个分区再用数字编号。比如我们前面多次用到的 /dev/sda ，还可以分成两个分区 /dev/sda1 和 /dev/sda2。

另一个比较常用的架构，是把多块磁盘组合成一个逻辑磁盘，构成冗余独立磁盘阵列，也就是** RAID（Redundant Array of Independent Disks）**，从而可以提高数据访问的性能，并且增强数据存储的可靠性。

根据容量、性能和可靠性需求的不同，RAID 一般可以划分为多个级别，如 RAID0、RAID1、RAID5、RAID10 等。

RAID0 有最优的读写性能，但不提供数据冗余的功能。
而其他级别的 RAID，在提供数据冗余的基础上，对读写性能也有一定程度的优化。

最后一种架构，是把这些磁盘组合成一个网络存储集群，再通过 NFS、SMB、iSCSI 等网络存储协议，暴露给服务器使用。

其实在 Linux 中，磁盘实际上是作为一个块设备来管理的，也就是以块为单位读写数据，并且支持随机读写。每个块设备都会被赋予两个设备号，分别是主、次设备号。主设备号用在驱动程序中，用来区分设备类型；而次设备号则是用来给多个同类设备编号。

通用块层（重点）

和虚拟文件系统 VFS 类似，为了减小不同块设备的差异带来的影响，Linux 通过一个统一的通用块层，来管理各种不同的块设备。

通用块层，其实是处在文件系统和磁盘驱动中间的一个块设备抽象层。它主要有两个功能：

第一个功能跟虚拟文件系统的功能类似。向上，为文件系统和应用程序，提供访问块设备的标准接口；向下，把各种异构的磁盘设备抽象为统一的块设备，并提供统一框架来管理这些设备的驱动程序。
第二个功能，通用块层还会给文件系统和应用程序发来的 I/O 请求排队，并通过重新排序、请求合并等方式，提高磁盘读写的效率。

其中，对 I/O 请求排序的过程，也就是我们熟悉的 I/O 调度。事实上，Linux 内核支持四种 I/O 调度算法，分别是：

NONE ，更确切来说，并不能算 I/O 调度算法。因为它完全不使用任何 I/O 调度器，对文件系统和应用程序的 I/O 其实不做任何处理，常用在虚拟机中（此时磁盘 I/O 调度完全由物理机负责）。
**NOOP **，是最简单的一种 I/O 调度算法。它实际上是一个先入先出的队列，只做一些最基本的请求合并，常用于 SSD 磁盘。
CFQ（Completely Fair Scheduler），也被称为完全公平调度器，是现在很多发行版的默认 I/O 调度器，它为每个进程维护了一个 I/O 调度队列，并按照时间片来均匀分布每个进程的 I/O 请求。类似于进程 CPU 调度，CFQ 还支持进程 I/O 的优先级调度，所以它适用于运行大量进程的系统，像是桌面环境、多媒体应用等。
**DeadLine **调度算法，分别为读、写请求创建了不同的 I/O 队列，可以提高机械磁盘的吞吐量，并确保达到最终期限（deadline）的请求被优先处理。DeadLine 调度算法，多用在 I/O 压力比较重的场景，比如数据库等。

文件系统层，包括虚拟文件系统和其他各种文件系统的具体实现。它为上层的应用程序，提供标准的文件访问接口；对下会通过通用块层，来存储和管理磁盘数据。
通用块层，包括块设备 I/O 队列和 I/O 调度器。它会对文件系统的 I/O 请求进行排队，再通过重新排序和请求合并，然后才要发送给下一级的设备层。
设备层，包括存储设备和相应的驱动程序，负责最终物理设备的 I/O 操作。

选择 I/O 调度程序

RHEL 8 包含新的多个队列 I/O 调度程序，⽤于取代基于单队列的 I/O 调度程序。新调度程序使用多队列块 I/O 队列机制 (blk-mq)，这使得 I/O 操作可以映射到多个硬件或软件请求队列。

Blk-mq 将 I/O 操作映射到不同的队列和执⾏线程。线程由各个 CPU 上的不同内核执⾏，可在多个执⾏线程对单个设备执⾏ I/O 时减少锁争⽤。较新的设备接⼝（如⾮易失性存储器表达 (NVMe) 协议）充分利⽤此功能，提供对多个硬件提交、完成队列和低延迟性能特性的原⽣⽀持。实现的性能增益由硬件特性和⼯作负载⾏为决定。

RHEL 8 包括四个多队列 I/O 调度程序设置：mq-deadline、kyber、bfq 和 none。各⾃在特定设备上具有性能优势，并且必须基于针对⽣产存储系统的基准测试选择调度程序。

mq-deadline

mq-deadline 调度程序实施旧有 I/O 调度程序的多个队列版本。此调度程序通过使⽤两个队列（⼀个用于写⼊，另⼀个用于读取）来缓解按过期时间排序的 I/O 操作不⾜，从⽽确保 I/O 操作（写⼊或读取）在过期之前执⾏。如果没有即将过期的时间，则从第三个队列执⾏ I/O 操作，该队列按扇区对请求进⾏排序。mq-deadline 调度程序是 RHEL 8 的默认设置，可以对其他多队列调度程序尚未处理的写⼊操作进⾏排序。

kyber

Kyber ⽀持具有两个队列的快速设备，⼀个用于处理同步（读取）请求，另⼀个用于处理异步（写入）请求。这些队列通过严格限制发送到队列的请求操作数量来管理每个请求的等待时间。这将限制等待调度请求的时间，并为⾼优先级的请求提供快速完成时间。Kyber 调度程序是处理吞吐量敏感型服务器负载的⾸选，在 SSD 上尤其如此，这主要是因为这个调度程序更简单，可以更快地处理请求。

bfq

BFQ 是对完全公平队列 (CFQ) 调度程序的改进，其中公平共享是基于所请求的扇区的数量和试探法，而不是时间片。BFQ 提供⼀致的交互式响应，特别是在较慢的设备硬盘器件上。BFQ 具有相对较⾼的每操作开销，当 I/O 操作速度慢且成本⾼昂时，这是可以接受的。如果 I/O 操作的成本较低，并且吞吐量⾄关重要，例如速度较慢的CPU，此时，则不要采⽤ BFQ。这个 I/O 调度程序是⽤于替代基于 cfq 单队列的 I/O 调度程序。在使⽤ SSD 处理服务器⼯作负载时，最好使⽤更简单的调度程序，如 Kyber。重视交互系统响应的用户，以及可能使用速度较慢的设备的用户可以选择 BFQ。

none

此设置不记录 I/O 请求，因此可以⽀持 NVMe 磁盘等快速随机 I/O 设备。这个 I/O 调度程序是⽤于替代基于 noop 单队列的 I/O 调度程序。

RHEL7磁盘默认调度算法是deadline

RHEL8磁盘默认调度算法是bfq

每种调度算法可调的参数也不同

如果选择noop，则没有任何可调参数，在RHEL8里设置为none，连iosched文件夹都没有

在 sysfs 中调优调度程序
在 sys ⽂件系统中，/sys/block/disk_device/queue/scheduler 会列出设备的可⽤ I/O 调度程序。当前活动的 I/O 调度程序列在⽅括号中。以下⽰例显⽰ mq-deadline 是 vda 设备的活动 I/O 调度程序。

[root@host ~]# cat /sys/block/vda/queue/scheduler
[mq-deadline] kyber bfq none

可⽤于磁盘上的活动 I/O 调度程序的可调项位于** /sys/block/disk_device/queue/iosched**⽬录中。以下⽰例显⽰了 vda 上的mq-deadline 调度程序的可调项。

[root@host ~]# ls /sys/block/vda/queue/iosched
fifo_batch front_merges read_expire write_expire writes_starved

临时修改：

$ echo 'none' > /sys/block/sda/queue/scheduler
$ cat           /sys/block/sda/queue/scheduler
[none] mq-deadline kyber bfq

永久修改：

# 修改策略，如改为none
mkdir /etc/tuned/ssdlinux

vi /etc/tuned/ssdlinux/tuned.conf
[disk]
elevator=none

# 触发生效
tuned-adm profile ssdlinux

如果要指定磁盘策略，可通过以下参数devices_udev_regex

[disk]
devices_udev_regex=IDNAME=device system unique id
elevator=selected-scheduler

使用场景：

HDD建议使用mq-deadline、bfq，SSD建议使用none、kyber；当使用共享存储时，建议不要使用任何调优算法也就是（none），因为共享存储底层已经做了调优，在主机上再设置调优算法意义不大，并且耗费宝贵的CPU时钟周期。

使用调优配置集调优存储

tuned 服务采⽤预定义的调优配置集，可⽀持多种⽤例。存储⽰例包括 latency-performance 和throughput-performance 配置集。可以创建⾃定义调优配置集来⽀持您的环境特定要求。有多种tuned 插件⽀持存储调优，例如：

disk 插件通过 elevator 参数配置要在设备上使⽤的 I/O 调度程序（电梯）
sysfs 插件使⽤ key = value 定义配置 I/O 调度程序的可调项。以下⽰例将 vda 设备的 fifo_batch 可调项配置为 1

[sysfs]
/sys/block/vda/queue/iosched/fifo_batch=1

测试磁盘性能

Windows

IOmeter是一款Inter开源的I/O测试工具

SSD盘（100%随机写场景）

SATA盘（100%随机写场景）

Linux

FIO是Linux下开源的一款IOPS测试工具，主要用来对磁盘进行压力测试和性能验证。
它可以产生许多线程或进程来执行用户特定类型的I/O操作，通过编写作业文件（类似于k8s的yaml）或者直接命令去执行测试动作，相当于是一个多线程的io生成工具，用于生成多种IO模式来测试硬盘设备的性能（大多情况用于测试裸盘性能）。

硬盘I/O测试主要有以下类型：

随机读、随机写
顺序读、顺序写

（fio测试时可根据需求设置70%读，30%写或100%读等等）

常用参数：

-filename=/dev/sdb		#要测试盘的名称，支持文件系统或者裸设备，/dev/sda2或/dev/sdb

-direct=1		 #测试过程绕过机器自带的buffer，使测试结果更真实（Linux在读写时，数据会先写到缓存，再在后台写到硬盘，读的时候也是优先从缓存中读，这样访问速度会加快，但是一旦掉电，缓存中数据就会清空，所有一种模式为DirectIO，可以跳过缓存，直接读写硬盘）

-ioengine=libaio		#定义使用什么io引擎去下发io请求，常用的一些 libaio：Linux本地异步I/O；rbd:通过librbd直接访问CEPH Rados 

-iodepth=16		 #队列的深度为16，在异步模式下，CPU不能一直无限的发命令到硬盘设备。比如SSD执行读写如果发生了卡顿，那有可能系统会一直不停的发命令，几千个，甚至几万个，这样一方面SSD扛不住，另一方面这么多命令会很占内存，系统也要挂掉了。这样，就带来一个参数叫做队列深度。

-bs=4k           #单次io的块文件大小为4k
-numjobs=10      #本次测试的线程数是10
-size=5G         #每个线程读写的数据量是5GB
-runtime=60      #测试时间为60秒，可以设置2m为两分钟。如果不配置此项，会将设置的size大小全部写入或者读取完为止

-rw=randread     #测试随机读的I/O
-rw=randwrite    #测试随机写的I/O
-rw=randrw       #测试随机混合写和读的I/O
-rw=read         #测试顺序读的I/O
-rw=write        #测试顺序写的I/O
-rw=rw           #测试顺序混合写和读的I/O
-thread          #使用pthread_create创建线程，另一种是fork创建进程。进程的开销比线程要大，一般都采用thread测试

rwmixwrite=30    #在混合读写的模式下，写占30%（即rwmixread读为70%，单独配置这样的一个参数即可）

-group_reporting     #关于显示结果的，汇总每个进程的信息
-name="TDSQL_4KB_read_test"     #定义测试任务名称

扩展
-lockmem=1g       #只使用1g内存进行测试
-zero_buffers     #用全0初始化缓冲区，默认是用随机数据填充缓冲区
-random_distribution=random    #默认情况下，fio 会在询问时使用完全均匀的随机分布，有需要的话可以自定义访问区域，zipf、pareto、normal、zoned
-nrfiles=8        #每个进程生成文件的数量

常用组合：

100%随机读，5G大小，4k块文件

fio -filename=/dev/sdb \
-direct=1 -ioengine=libaio \
-bs=4k -size=5G -numjobs=10 \
-iodepth=16 -runtime=60 \
-thread -rw=randread -group_reporting \
-name="TDSQL_4KB_randread_test"

100%顺序读，5G大小，4k块文件

fio -filename=/dev/sdb \
-direct=1 -ioengine=libaio \
-bs=4k -size=5G -numjobs=10 \
-iodepth=16 -runtime=60 \
-thread -rw=read -group_reporting \
-name="TDSQL_4KB_write_test"

70%随机读，30%随机写，5G大小，4k块文件

fio -filename=/dev/sdb \
-direct=1 -ioengine=libaio \
-bs=4k -size=5G -numjobs=10 \
-iodepth=16 -runtime=60 \
-thread -rw=randrw -rwmixread=70 \
-group_reporting \
-name="TDSQL_4KB_randread70-write_test"

70%顺序读，30%随机写，5G大小，4k块文件

fio -filename=/dev/sdb \
-direct=1 -ioengine=libaio \
-bs=4k -size=5G -numjobs=10 \
-iodepth=16 -runtime=60 \
-thread -rw=rw -rwmixread=70 \
-group_reporting \
-name="TDSQL_4KB_read70-write_test"

输出报告分析：

[root@host]# fio -filename=/dev/sdb \
> -direct=1 -ioengine=libaio \
> -bs=4k -size=5G -numjobs=10 \
> -iodepth=16 -runtime=60 \
> -thread -rw=randrw -rwmixread=70 \
> -group_reporting \
> -name="local_randrw_test"
local_randrw_test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=16
...
fio-3.10
Starting 10 threads
Jobs: 10 (f=10): [m(10)][100.0%][r=19.4MiB/s,w=8456KiB/s][r=4969,w=2114 IOPS][eta 00m:00s]
local_randrw_test: (groupid=0, jobs=10): err= 0: pid=11189: Mon Oct 25 11:01:46 2021
   read: IOPS=5230, BW=20.4MiB/s (21.4MB/s)(1226MiB/60031msec)
    slat (usec): min=2, max=342637, avg=1266.82, stdev=7241.29
    clat (usec): min=4, max=459544, avg=20056.81, stdev=24888.90
     lat (usec): min=134, max=459586, avg=21329.16, stdev=25378.16
    clat percentiles (usec):
     |  1.00th=[  1467],  5.00th=[  1844], 10.00th=[  2147], 20.00th=[  2606],
     | 30.00th=[  3032], 40.00th=[  3556], 50.00th=[  4359], 60.00th=[  6063],
     | 70.00th=[ 36439], 80.00th=[ 46924], 90.00th=[ 51643], 95.00th=[ 59507],
     | 99.00th=[105382], 99.50th=[117965], 99.90th=[137364], 99.95th=[152044],
     | 99.99th=[219153]
   bw (  KiB/s): min=  795, max= 4494, per=9.91%, avg=2072.23, stdev=744.04, samples=1195
   iops        : min=  198, max= 1123, avg=517.74, stdev=186.00, samples=1195
  write: IOPS=2243, BW=8972KiB/s (9188kB/s)(526MiB/60031msec)
    slat (usec): min=2, max=311932, avg=1272.76, stdev=7272.09
    clat (usec): min=6, max=458031, avg=20206.30, stdev=24897.71
     lat (usec): min=974, max=459755, avg=21484.12, stdev=25400.41
    clat percentiles (usec):
     |  1.00th=[  1500],  5.00th=[  1860], 10.00th=[  2147], 20.00th=[  2606],
     | 30.00th=[  3064], 40.00th=[  3621], 50.00th=[  4424], 60.00th=[  6194],
     | 70.00th=[ 36439], 80.00th=[ 46924], 90.00th=[ 51643], 95.00th=[ 59507],
     | 99.00th=[105382], 99.50th=[117965], 99.90th=[137364], 99.95th=[149947],
     | 99.99th=[200279]
   bw (  KiB/s): min=  357, max= 1944, per=9.90%, avg=888.57, stdev=325.49, samples=1195
   iops        : min=   89, max=  486, avg=221.80, stdev=81.37, samples=1195
  lat (usec)   : 10=0.01%, 50=0.01%, 100=0.01%, 250=0.02%, 500=0.01%
  lat (usec)   : 750=0.01%, 1000=0.01%
  lat (msec)   : 2=7.45%, 4=38.36%, 10=18.10%, 20=1.09%, 50=22.31%
  lat (msec)   : 100=11.42%, 250=1.24%, 500=0.01%
  cpu          : usr=0.26%, sys=19.41%, ctx=12026, majf=0, minf=18
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=313975,134655,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
   READ: bw=20.4MiB/s (21.4MB/s), 20.4MiB/s-20.4MiB/s (21.4MB/s-21.4MB/s), io=1226MiB (1286MB), run=60031-60031msec
  WRITE: bw=8972KiB/s (9188kB/s), 8972KiB/s-8972KiB/s (9188kB/s-9188kB/s), io=526MiB (552MB), run=60031-60031msec

Disk stats (read/write):
  sdb: ios=314008/134653, merge=0/0, ticks=189470/89778, in_queue=279286, util=99.75%

read/write：读/写的IO操作（还有一个trim没用过）

salt：提交延迟，这是提交I/O所花费的时间（min:最小值，max:最大值，avg:平均值，stdev:标准偏差）
chat：完成延迟，表示从提交到完成I/O部分的时间
lat：相应时间，表示从fio创建I/O单元到完成I/O操作的时间
bw：带宽统计
iops： IOPS统计

lat(nsec/usec/msec)： I/O完成延迟的分布。这是从I/O离开fio到它完成的时间。与上面单独的读/写/修剪部分不同，这里和其余部分的数据适用于报告组的所有I/ o。10=0.01%意味着0.01%的I/O在250us以下完成。250=0.02%意味着0.02%的I/O需要10到250us才能完成。

IO depths： I/O深度在作业生命周期中的分布

IO submit：在一个提交调用中提交了多少个I/O。每一个分录表示该数额及其以下，直到上一分录为止——例如，4=100%意味着我们每次提交0到4个I/O调用
IO complete：和上边的submit一样，不过这个是完成了多少个
IO issued rwt：发出的read/write/trim请求的数量，以及其中有多少请求被缩短或删除
IO latency：满足指定延迟目标所需的I/O深度

下面是Run status group 0 (all jobs) 全部任务汇总信息的代表值含义：

bw：总带宽以及最小和最大带宽
io：该组中所有线程执行的累计I/O
run：这组线程中最小和最长的运行时。

最后是Linux中特有的磁盘状态统计信息的代表值含义：

ios：所有组的I/ o个数
merge： I/O调度器执行的总合并数
ticks：使磁盘繁忙的滴答数（仅供参考，原文是Number of ticks we kept the disk busy）
in_queue：在磁盘队列中花费的总时间
util：磁盘利用率。值为100%意味着我们保留了磁盘，如果一直很忙，那么50%的时间磁盘就会闲置一半的时间

磁盘I/O观测

磁盘性能指标:：

使用率，是指磁盘处理 I/O 的时间百分比。过高的使用率（比如超过 80%），通常意味着磁盘 I/O 存在性能瓶颈。
饱和度，是指磁盘处理 I/O 的繁忙程度。过高的饱和度，意味着磁盘存在严重的性能瓶颈。当饱和度为 100% 时，磁盘无法接受新的 I/O 请求。
IOPS（Input/Output Per Second），是指每秒的 I/O 请求数。
吞吐量，是指每秒的 I/O 请求大小。
响应时间，是指 I/O 请求从发出到收到响应的间隔时间。

iostat 是最常用的磁盘 I/O 性能观测工具，它提供了每个磁盘的使用率、IOPS、吞吐量等各种常见的性能指标，这些指标实际上来自 /proc/diskstats。

# -d -x 表示显示所有磁盘 I/O 的指标
$ iostat -d -x 1 
Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  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   0.00   0.00 
loop1            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   0.00   0.00 
sda              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   0.00   0.00 
sdb              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   0.00   0.00

%util ，就是我们前面提到的磁盘 I/O 使用率；
r/s+ w/s ，就是 IOPS；
rkB/s+wkB/s ，就是吞吐量；
r_await+w_await ，就是响应时间。

进程 I/O 观测

除了每块磁盘的 I/O 情况，每个进程的 I/O 情况也是我们需要关注的重点。

上面提到的 iostat 只提供磁盘整体的 I/O 性能数据，缺点在于，并不能知道具体是哪些进程在进行磁盘读写。要观察进程的 I/O 情况，你还可以使用** pidstat** 和** iotop **这两个工具。

pidstat -d ，你就可以看到进程的 I/O 情况，如下所示：

$ pidstat -d 1 
13:39:51      UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command 
13:39:52      102       916      0.00      4.00      0.00       0  rsyslogd

输出详解：

用户 ID（UID）和进程 ID（PID）。
每秒读取的数据大小（kB_rd/s），单位是 KB。
每秒发出的写请求数据大小（kB_wr/s），单位是 KB。
每秒取消的写请求数据大小（kB_ccwr/s），单位是 KB。
块 I/O 延迟（iodelay），包括等待同步块 I/O 和换入块 I/O 结束的时间，单位是时钟周期。

除了可以用 pidstat 实时查看，根据 I/O 大小对进程排序，也是性能分析中一个常用的方法。这一点，我推荐另一个工具， iotop。它是一个类似于 top 的工具，你可以按照 I/O 大小对进程排序，然后找到 I/O 较大的那些进程。

iotop 的输出如下所示：

$ iotop
Total DISK READ :       0.00 B/s | Total DISK WRITE :       7.85 K/s 
Actual DISK READ:       0.00 B/s | Actual DISK WRITE:       0.00 B/s 
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND 
15055 be/3 root        0.00 B/s    7.85 K/s  0.00 %  0.00 % systemd-journald

从这个输出，你可以看到，前两行分别表示，进程的磁盘读写大小总数和磁盘真实的读写大小总数。因为缓存、缓冲区、I/O 合并等因素的影响，它们可能并不相等。

剩下的部分，则是从各个角度来分别表示进程的 I/O 情况，包括线程 ID、I/O 优先级、每秒读磁盘的大小、每秒写磁盘的大小、换入和等待 I/O 的时钟百分比等。

磁盘 I/O 性能优化的几个思路

I/O 基准测试

按照我的习惯，优化之前，我会先问自己， I/O 性能优化的目标是什么？换句话说，我们观察的这些 I/O 性能指标（比如 IOPS、吞吐量、延迟等），要达到多少才合适呢？

事实上，I/O 性能指标的具体标准，每个人估计会有不同的答案，因为我们每个人的应用场景、使用的文件系统和物理磁盘等，都有可能不一样。

为了更客观合理地评估优化效果，我们首先应该对磁盘和文件系统进行基准测试，得到文件系统或者磁盘 I/O 的极限性能。

fio（Flexible I/O Tester）正是最常用的文件系统和磁盘 I/O 性能基准测试工具。它提供了大量的可定制化选项，可以用来测试，裸盘或者文件系统在各种场景下的 I/O 性能，包括了不同块大小、不同 I/O 引擎以及是否使用缓存等场景。

应用程序优化

应用程序处于整个 I/O 栈的最上端，它可以通过系统调用，来调整 I/O 模式（如顺序还是随机、同步还是异步），同时，它也是 I/O 数据的最终来源。在我看来，可以有这么几种方式来优化应用程序的 I/O 性能。

可以用追加写代替随机写，减少寻址开销，加快 I/O 写的速度。
可以借助缓存 I/O ，充分利用系统缓存，降低实际 I/O 的次数。
可以在应用程序内部构建自己的缓存，或者用 Redis 这类外部缓存系统。这样，一方面，能在应用程序内部，控制缓存的数据和生命周期；另一方面，也能降低其他应用程序使用缓存对自身的影响。如， C 标准库提供的 fopen、fread 等库函数，都会利用标准库的缓存，减少磁盘的操作。而你直接使用 open、read 等系统调用时，就只能利用操作系统提供的页缓存和缓冲区等，而没有库函数的缓存可用。
在需要频繁读写同一块磁盘空间时，可以用 mmap 代替 read/write，减少内存的拷贝次数。
在需要同步写的场景中，尽量将写请求合并，而不是让每个请求都同步写入磁盘，即可以用 fsync() 取代 O_SYNC。
在多个应用程序共享相同磁盘时，为了保证 I/O 不被某个应用完全占用，推荐你使用 cgroups 的 I/O 子系统，来限制进程 / 进程组的 IOPS 以及吞吐量。
在使用 CFQ 调度器时，可以用 ionice 来调整进程的 I/O 调度优先级，特别是提高核心应用的 I/O 优先级。ionice 支持三个优先级类：Idle、Best-effort 和 Realtime。其中， Best-effort 和 Realtime 还分别支持 0-7 的级别，数值越小，则表示优先级别越高。

文件系统优化

应用程序访问普通文件时，实际是由文件系统间接负责，文件在磁盘中的读写。所以，跟文件系统中相关的也有很多优化 I/O 性能的方式。

根据实际负载场景的不同，选择最适合的文件系统。比如 Ubuntu 默认使用 ext4 文件系统，而 CentOS 7 默认使用 xfs 文件系统。

相比于 ext4 ，xfs 支持更大的磁盘分区和更大的文件数量，如 xfs 支持大于 16TB 的磁盘。但是 xfs 文件系统的缺点在于无法收缩，而 ext4 则可以。

在选好文件系统后，还可以进一步优化文件系统的配置选项，包括文件系统的特性（如 ext_attr、dir_index）、日志模式（如 journal、ordered、writeback）、挂载选项（如 noatime）等等。

比如，使用 tune2fs 这个工具，可以调整文件系统的特性（tune2fs 也常用来查看文件系统超级块的内容）。而通过 /etc/fstab ，或者 mount 命令行参数，我们可以调整文件系统的日志模式和挂载选项等。

可以优化文件系统的缓存

比如，你可以优化 pdflush 脏页的刷新频率（比如设置 dirty_expire_centisecs 和 dirty_writeback_centisecs）以及脏页的限额（比如调整 dirty_background_ratio 和 dirty_ratio 等）。
再如，你还可以优化内核回收目录项缓存和索引节点缓存的倾向，即调整 vfs_cache_pressure（/proc/sys/vm/vfs_cache_pressure，默认值 100），数值越大，就表示越容易回收。

在不需要持久化时，还可以用内存文件系统 tmpfs，以获得更好的 I/O 性能 。tmpfs 把数据直接保存在内存中，而不是磁盘中。比如 /dev/shm/ ，就是大多数 Linux 默认配置的一个内存文件系统，它的大小默认为总内存的一半。

磁盘优化

数据的持久化存储，最终还是要落到具体的物理磁盘中，同时，磁盘也是整个 I/O 栈的最底层。从磁盘角度出发，自然也有很多有效的性能优化方法。

最简单有效的优化方法，就是换用性能更好的磁盘，比如用 SSD 替代 HDD。

SSD优化：https://codecapsule.com/2014/02/12/coding-for-ssds-part-1-introduction-and-table-of-contents/

我们可以使用 RAID ，把多块磁盘组合成一个逻辑磁盘，构成冗余独立磁盘阵列。这样做既可以提高数据的可靠性，又可以提升数据的访问性能。
针对磁盘和应用程序 I/O 模式的特征，我们可以选择最适合的 I/O 调度算法。比方说，SSD 和虚拟机中的磁盘，通常用的是 noop 调度算法。而数据库应用，我更推荐使用 deadline 算法。
我们可以对应用程序的数据，进行磁盘级别的隔离。比如，我们可以为日志、数据库等 I/O 压力比较重的应用，配置单独的磁盘。
在顺序读比较多的场景中，我们可以增大磁盘的预读数据，比如，你可以通过下面两种方法，调整 /dev/sdb 的预读大小。

调整内核选项 /sys/block/sdb/queue/read_ahead_kb，默认大小是 128 KB，单位为 KB。
使用 blockdev 工具设置，比如 blockdev --setra 8192 /dev/sdb，注意这里的单位是 512B（0.5KB），所以它的数值总是 read_ahead_kb 的两倍。

优化内核块设备 I/O 的选项。比如，可以调整磁盘队列的长度 /sys/block/sdb/queue/nr_requests，适当增大队列长度，可以提升磁盘的吞吐量（当然也会导致 I/O 延迟增大）。
磁盘本身出现硬件错误，也会导致 I/O 性能急剧下降，所以发现磁盘性能急剧下降时，你还需要确认，磁盘本身是不是出现了硬件错误。

比如，你可以查看 dmesg 中是否有硬件 I/O 故障的日志。还可以使用 badblocks、smartctl 等工具，检测磁盘的硬件问题，或用 e2fsck 等来检测文件系统的错误。如果发现问题，你可以使用 fsck 等工具来修复。

posted @ 2023-03-25 09:43 风有遗霜阅读(905) 评论(0) 收藏举报

刷新页面返回顶部

风有遗霜