性能之巅:洞悉系统、企业与云计算——磁盘

磁盘 I/O 可能会造成严重的应用程序延时，因此是系统分析的一个重要目标。在高负载下，磁盘成为瓶颈，CPU持续空闲以等待磁盘 I/O 结束。发现并消除这些瓶颈能让性能和应用程序吞吐量翻好几倍。

磁盘指系统的主要存储设备。这包括了旋转磁性盘片和基于闪存的固态盘（SSD）。引入后者主要是为了提高磁盘的 I/O 性能，而事实上的确做到了。然而，对容量和 I/O 速率的需求仍在不断增长，闪存设备并不能完全解决性能问题。

术语

• 虚拟磁盘：存储设备的模拟。在系统看来，这是一块物理磁盘，但是，它可能由多块磁盘组成。
• 传输总线：用来通信的物理总线，包括数据传输（I/O）以及其他磁盘命令。
• 扇区：磁盘上的一个存储块，通常是 512B 大小。
• I/O ：对于磁盘，严格地说仅仅包括读和写，而不包括其他磁盘命令。I/O 至少由放心（读或写）、磁盘地址（位置）和大小（字节数）组成。
• 磁盘命令：除了读写之外，磁盘还会被指派执行其他非数据传输的命令（例如缓存写回）。
• 吞吐量：对于磁盘而言，吞吐量通常指当前数据传输速率，单位是 B/s。
• 带宽：这是存储传输或者控制器能够达到的最大数据传输速率。
• I/O 延时：一个 I/O 操作的执行时间，这个词在操作系统领域广泛使用，早已超出了设备层。注意在网络领域，这个词有其他的意思，指发起一个 I/O 延时，后面跟着数据传输时间。
• 延时离群点：非同寻常的高延时磁盘 I/O。

模型

简单磁盘

现代磁盘包括了一个盘上的 I/O 请求队列，如下图所示。

磁盘接受的 I/O 请求要么在队列等待，要么正在处理中。这个简单模型就像超市的收银口，顾客们排队来等待服务，这也很适合用排队理论进行分析。

虽然这看上去好像是一个先来后到的队列，事实上磁盘管理器可以为了优化性能而采用其他算法。这些算法包括了旋转磁盘的电梯寻道算法，或者对读写I/O 准备分开的队列（特别是闪存盘）。

缓存磁盘

磁盘缓存的加入使有些读请求可以从更快的内存介质中返回，如下图所示。只要物理磁盘设备的一小块闪存（DRAM）就可以达到这种效果。

虽然缓存的命中可以代理非常低的延时，高延时的缓存未命中却仍然是磁盘设备的主旋律。

盘上的缓存也可以用作写回缓存以提高写性能。在数据写到缓存后，磁盘就通知写入已经结束，之后再把数据写入到较慢的永久磁盘存储介质中。与之相对的另一种做法叫写缓存，只有当写完全进入到下一层再返回。

控制器

下图演示了一种简单的磁盘控制器，把 CPU I/O 传输总线和存储总线以及相连的磁盘设备桥接起来。这个设备又称为主机总线适配器（host bus adaptor，HBA）。

其性能可能受限于其中任何一个组件，包括总线，磁盘控制器和磁盘。

概念

测量时间

存储设备的响应（也叫磁盘 I/O 延时）指的是从 I/O 请求到结束时间。它由服务和等待时间组成。

• 服务时间：I/O 得到主动处理（服务）的时间，不包括在队列中等待时间
• 等待时间：I/O 在队列中等待服务的时间

下图展示了测量时间的构成，以及其他一些术语：

响应时间、服务时间和等待时间全部取决于测量处的位置。下面将从操作系统和磁盘上下文角度进行描述（也是一种简化）

• 从操作系统（块设备接口）角度来说，服务时间可以从 I/O 请求发到磁盘设备开始计算，到结束中断发生为止。它并不包括在操作系统队列等待的时间。仅仅反映了磁盘设备对操作请求的总体性能。
• 而对于磁盘而言，服务时间指从磁盘开始主动服务 I/O 开始算起，不包括在磁盘队列里等待的任何时间。

服务时间来源于早期，当时磁盘都是一些简单的设备，由操作系统直接管理。对于磁盘是否在服务 I/O，操作系统可谓是了若指掌。而今磁盘由了自己的内部队列，操作系统的服务时间却包括了在设备队列等待的时间。操作系统这个指标，其实应该称为“磁盘响应时间”更为准确。

响应时间也可以从多个角度来看。比如，“磁盘响应时间” 可以描述从操作系统角度观测到的服务时间，而“I/O响应时间”可以描述从操作系统角度观测到的服务时间，而“I/O响应时间”则是从应用程序角度出发，可包括系统调用层以下的时间总和（服务时间、所有等待时间和代码执行时间）。

块设备接口的服务时间通常作为磁盘性能的一个指标（也是iostat(1) 展示的），但是始终牢记这只是一种简化。

计算时间

磁盘服务时间通常不从操作系统直接观测而来，相反，平均磁盘服务时间通过 IOPS 和使用率推算出来：

磁盘服务时间 = 使用率 / IOPS

时间尺度

磁盘 I/O 的时间尺度千差完别，从几十微妙到数千毫秒。在最慢的一端，单个慢磁盘 I/O 可能导致糟糕的应用程序响应时间；而在最快的一端，只有在数量很大的时候性能才会出现问题（很多快 I/O 的总和等于一个慢 I/O）。

下表列出了磁盘 I/O 延时时间可能出现的一个大致范围。如果想得到准确和时下的数值，那就要查阅磁盘供应商的文档，并自己做一些微基准测试。

为了更好地演示相关的时间数量级，表中“比例”一列以在理想情况下磁盘缓存命中时间为1s，按比例放大。

磁盘 I/O 延时时间尺度比例

事件	延时	比例
磁盘缓存命中	<100us	1s
读闪存	约 100 ~ 1000us（I/O 由小到大）	1 ~ 10s
机械磁盘连续读	约 1ms	10s
机械磁盘随机读（7200转）	约 8ms	1.3分钟
机械磁盘随机读（慢，排队）	> 10ms	1.7分钟
机械磁盘随机读（队列较长）	> 100ms	17分钟
最差情况的虚拟磁盘 I/O（硬盘控制器、RAID-5、排队、随机 I/O）	> 1000ms	2.8小时

这些延时在不同环境需求下有不同的含义。对于一个工作在企业存储领域的人来说，任何大于10ms的磁盘I/O 都过于漫长，很可能有性能问题。云计算领域则能容忍更高的延时，特别是对于基于Web的应用程序，本来客户端和浏览器之间的网络延时已经很高了。在这些环境里，磁盘 I/O 只有在超过 100ms 时才是问题（单个 I/O 时间，或者一个应用程序请求期间的时间总和）。

缓存

最好的磁盘 I/O 性能就是没有 I/O。许多软件栈尝试通过缓存读和缓冲写来避免磁盘I/O抵达磁盘。下表列出了在磁盘设备驱动层甚至更下层的缓存。

缓存	示列
设备缓存	ZFS vdev
块缓存	缓冲区高速缓存
磁盘控制器缓存	RAID 卡缓存
存储阵列缓存	阵列缓存
磁盘缓存	磁盘数据控制器（DDC）附带 DRAM

随机 vs 连续 I/O

根据磁盘上I/O 的相对位置（磁盘偏移量），可以用术语随机和连续描述磁盘 I/O 负载。

连续负载也称为流负载。术语”流“一般用于应用层，用来描述对”磁盘“（文件系统）的流式读和写。

在磁性旋转磁盘时代，随机与连续磁盘 I/O 模式之间的对比是研究的中断。随机 I/O 带来的磁头寻道和 I/O 之间的盘片旋转导致额外的延时。下图展示了这一情况，磁头从扇区1 到扇区2 需要寻道和旋转两个动作（实际路径是越直接越好）。性能调优的工作就包含识别并通过一些手段排查随机 I/O，例如缓存、分离随机 I/O 到不同的磁盘，以及减少寻道距离为目的的数据摆放。

其他类型的硬盘，包括基于闪存的 SSD，在执行随机和连续 I/O 时通常没什么区别。不过还是有一些由其他因素造成的细微差别，具体取决于硬盘本身，例如地址查找缓存可以应对连续 I/O，却对随机 I/O 无能为力。

需要注意的是，从操作系统角度看到的磁盘偏移量并不一定是物理磁盘的偏移量。例如，硬件提供的虚拟磁盘可能把一块连续便宜量范围映射到多块磁盘。磁盘自己可能会按自己的方式重新映射偏移量（通过磁盘数据控制）。有时随机 I/O 并不通过检查偏移量的方式确定，而是由服务时间上升来推断。

读/写比

除了识别是随机还是连续负载之外，另一个度量特征是读写比例，已 IOPS 或者吞吐量相关。还可以通过一段时间内的比例来表示。例如，”系统启动后读的比例占到80%“。

理解这个比例有助于设计和配置系统。一个读频率较高的系统可以通过增加缓存来获得性能提升，而一个写频率较高的系统则可以通过增加磁盘来提高最大吞吐量和 IOPS。

读和写本身可以是不同的负载模式：读可能是随机的，而写可能是连续的（特别是写时复制的文件系统）。它们的 I/O 大小可能不尽相同。

I/O 大小

另一个负载特征是 I/O 的平均大小（字节数），或者 I/O 大小的分布。更大的 I/O 一般提供了更大的吞吐量，尽管单位 I/O 的延时有所上升。

磁盘设备子系统可能会改变 I/O 大小（例如量化到512字节块）。由于 I/O 从应用程序层发起，大小可能会因一些内核组件而放大或缩小，比如文件系统、卷管理器和设备驱动。

有些磁盘设备，特别是基于闪存的设备，对不同的读写大小有非常不同的行为。比如，一个基于闪存的磁盘驱动器可能在4KB 读和 1MB 写时表现得最好。理想的I/O 大小可以查阅磁盘供应商的文档，或者通过微基准测试获得。当前使用的I/O大小可以通过观察工具获得。

IOPS 并不平等

IOPS 并非生而平等，不能在不同设备和负载的情况下进行简单比较。一个IOPS值本身没有太多的意义，并不能单独用来准确比较负载。

例如，对于机械磁盘，5000 IOPS的联系负载可能比 1000 IOPS 的随机负载快得多。基于闪存的 IOPS 同样也很难比较，因为它们的I/O 性能通常和 I/O 大小及放心（读或写）紧密相关。

有意义的IOPS 需要包含其他细节：随机或者连续、I/O大小、读写比。另外考虑使用基于时间的指标，比如使用率和服务时间，以反映性能结果，并且可以更简单地进行比较。

非数据传输磁盘命令

除了读写 I/O，磁盘还可以接收其他命令。比如，可以命令带有缓存的磁盘（RAM）把缓存写回磁盘上。这种命令不是数据传输，数据之前已经通过写命令发送给磁盘。这些命令会影响性能，造成磁盘运作而让其他 I/O 等待。

使用率

使用率可以通过某段时间内磁盘运行工作的忙时间的比例计算得出。

一块使用率为 0%的磁盘是”空闲“的，而一块使用率为100%的磁盘一直在执行 I/O 。100%的磁盘使用率更可能是性能根源问题，特别是使用率在一段时间内都停留在100%。但是，任意数值的磁盘使用率都可能导致糟糕的性能，毕竟磁盘 I/O 是一个想对缓慢的活动。

在0% 和100% 之间可能有一个点（比如60%），由于在磁盘队列或者操作系统里排队的可能性增加，这个点的磁盘性能不再令人满意。至于到底多少的使用会成为问题，取决于磁盘、负载和延时需求。

为了确定高使用率是否会导致应用程序出现问题，需要研究磁盘的反应时间和应用程序是否被阻塞在此 I/O之上。应用程序或者操作系统可能异步地执行 I/O，这样，慢 I/O 不会直接导致应用程序等待。

注意使用率是一段时间的总结。磁盘I/O 可能突然爆发，特别是在批量刷新缓存时，而这种爆发可能被长时间的统计所摊平。

虚拟磁盘使用率

对于基于硬件的虚拟磁盘（比如磁盘控制器），操作系统可能只知道虚拟磁盘的忙时间，却不清楚底下磁盘的性能。这导致在某些情况下，操作系统报告的虚拟磁盘使用率和实际磁盘的情况有大出入（并且和直接相冲突）。

• 包含写回缓存的虚拟磁盘可能在写负载的时候看上去并不是很忙，因为磁盘控制器马上返回了写完成。但是底下的磁盘可能在之后的某个时间会很忙。
• 一块 100%占用的虚拟磁盘是建立在多块物理磁盘之上的。可能还可以接受更多的工作。在这种情况下，100%可能意味着有些磁盘一直都很忙，但并不是所有的磁盘在所有的时间内都很忙，有一些磁盘仍然有空闲时间。

基于相同的原因，由操作系统软件（软RAID）创建的虚拟磁盘使用率也不好理解。但是，操作系统应该显示物理磁盘的使用率以供查看。

一旦一块物理磁盘达到100%的使用率，向它发更多的I/O 会让磁盘饱和。

饱和度

饱和度度量了因超出资源服务能力而排队的工作。对于磁盘设备，它可以通过操作系统的磁盘等待队列的长度（假设启用了排队）计算得出。

这给100%以上的使用率提供了性能度量。一块100% 使用率的磁盘可能并未饱和（排队），或者非常饱和，导致排队 I/O 严重影响性能。

可以假设低于100% 使用率的磁盘没有饱和。但是，这取决于使用率窗口：一段时间内50%的磁盘使用率可能意味着一半时间内的100%使用率，外加剩下时间内完全空闲。所有单位时间的汇总都可能被相似的问题困扰。如果了解确切信息很重要的话，可以跟踪检查 I/O 时间。

I/O 等待

I/O 等待是针对单个CPU 的性能指标，表示当 CPU 分发队列（在睡眠台）里有线程被阻塞在磁盘 I/O 上市消耗的空闲时间。这就把CPU空闲时间划分成无所事事的真正空闲时间，以及阻塞在磁盘 I/O 上的时间。较高的每 CPU I/O 等待时间表示磁盘可能是瓶颈所在，导致CPU 等待而空闲。

I/O等待可能是一个令人非常困惑的指标。如果另一个CPU 饥饿型的进程也开始执行，I/O 等待值可能会下降：CPU现在有工作要做，而不会空闲着。但尽管 I/O 等待指标下降了，磁盘 I/O 还是和原来一样阻塞线程。与此相反，有时候系统管理员升级了应用程序软件，新版本的软件提高了效率，使用较少的CPU，把 I/O 等待问题暴露了出来，这会让系统管理员认为软件升级导致了磁盘问题，降低了性能。然而事实上磁盘性能并没有变化，CPU 性能却提高了。

一个更可靠的指标可能是应用程序线程阻塞在磁盘 I/O 上的时间。这个指标捕捉了应用程序线程因磁盘 I/O 导致的延时，而与CPU 正在执行的其他工作无关。这个指标可以用静态或者动态跟踪的方法测量。

I/O 等待在Linux上仍然是个广泛应用的指标，尽管它本身有些模糊，但可以用来识别一类磁盘瓶颈：忙磁盘、闲CPU。一种观点认为，任何 I/O 等待都是系统瓶颈的迹象，然后对系统进行调优以最小化它——即使 I/O 仍和 CPU 并发运行。并发I/O 更可能是非阻塞I/O，也较少直接导致问题。非并发I/O 容易因I/O 等待暴露出来，更可能成为阻塞应用程序I/O 的瓶颈。

同步 vs 异步

如果应用程序和磁盘 I/O 是异步的，那磁盘 I/O 延时可能不直接影响应用程序性能，理解这点很重要。通常这发送在写回缓存上，应用程序 I/O 早已完成，而磁盘 I/O 稍后发出。

应用程序可能用预读执行异步读，在磁盘读取的时候，可能不阻塞应用程序。文件系统也有可能使用类似的手段来预热缓存（于取）。

即使应用程序同步等待I/O，该程序代码路径可能并不在系统的关键路径上，而对客户端应用程序的响应可能是异步的。

磁盘 vs 应用程序 I/O

磁盘 I/O 是多个内核组件的终点，包括文件系统和设备驱动。磁盘 I/O 与应用程序发出的I/O 在频率和大小上都不匹配，背后有很多原因，如下所示：

• 文件系统放大，缩小和不相关的I/O 。
• 由于系统内存短缺造成的换页。
• 设备驱动 I/O 大小：I/O 大小的向上取整，或者 I/O 的碎片化。

架构

磁盘类型

市面上最常用的两种磁盘类型是磁性旋转机械盘和基于闪存的 SSD。这两种磁盘都提供了永久的存储；与易失性存储相反，里面存储的内容在断电之后仍然不会丢失。

磁性旋转盘

又被称为硬盘驱动器（HDD），也就是机械磁盘。既然是机械设备，那速度自然相对较慢。随着基于闪存技术的发展，SSD 正在替代机械磁盘。

寻道和旋转

磁性旋转磁盘的慢 I/O 通常由磁头寻道时间和盘片旋转时间造成，这二者通常需要花费数毫秒。最好的情况是下一个请求的 I/O 整合位于当前服务器 I/O 的结束位置，这样磁头就不需要寻道或者额外等待盘片选择。

有许多方法可以降低寻道和旋转等待时间，如下：

• 缓存：彻底消除 I/O 。
• 文件系统布置和行为，包括写时复制。
• 把不同的负载分散到不同的磁盘，避免不同负载之间的寻道。
• 把不同的负载移到不同的系统
• 电梯寻道，磁盘自身执行
• 高密度磁盘，可以把负载落盘的位置变得更紧密
• 分区（或者”切块“）配置，例如短行程

另一个降低旋转延时时间的办法就是使用更快的磁盘。

磁盘有多种不同的旋转速度，包括每分钟5400转、7200转、10 000转（10k）和15 000转（15k）(rpm)

理论最大吞吐量

如果已知一块磁盘每个磁道上的最大扇区数，磁盘吞吐量可以通过以下公式计算出来：

最大吞吐量 = 每磁道最大扇区数 * 扇区大小 * rpm / 60s

这个公式对于准确透露此类信息的较早磁盘较为有用。现代磁盘给操作系统提供了一个虚拟磁盘镜像，这类属性都是虚构的。

短行程

短行程指的是只把磁盘外侧的磁道用来服务负载，剩下的部分要么留着不用，要么留给那些低吞吐量的负载（例如归档）。由于磁头移动被限制在了一个较小的区域，寻道时间降低了，并且由于磁头在空闲时靠在外侧边缘，空闲后的第一次寻道时间也降低了。外侧的磁道由于扇区分区的缘故具有更高的吞吐量。

扇区分区

磁盘的磁道长度各不相同，磁盘中心区域的磁道较短，而外侧的磁道较长。相比固定的每磁道扇区数（和位数），由于物理上较长磁道能够写入更多的扇区，扇区分区增加了扇区个数。因为旋转速度一定，较长的外侧磁道比内侧磁道能够代理更高的吞吐量(MB/s)。

扇区大小

存储行业为磁盘设备开发了一种新标准，叫做高级格式（Advanced Format），以支持更大的扇区大小，特征4KB。这降低了I/O 计算的开销，提高了吞吐量，降低了每个扇区存储的元数据量。磁盘固件仍然可以通过一种高级格式512B的仿真标准来提供512B大小的扇区。具体取决于各个磁盘，这可能会增加写开销，在把512B映射到4KB扇区时造成一个额外的读—改—写的周期。其他已知的问题还包括不对齐的4KB I/O，横跨两个扇区，放大服务请求的扇区 I/O。

磁盘缓存

这些磁盘共有的一个部件是一小块内存（RAM），用来缓存读取的结果和缓冲要写入的数据。这块内存还允许I/O （命令）在设备上排队，以更高效的方式重新排序。在SCSI上，这被称为标记命令排队（Tagged Command Queueing，TCQ），而在SATA 上名为原生指令排队（Native command Queueing，NCQ）。

闪存

基于闪存的SSD 是一种读性能非常高的存储设备，尤其在随机读方面比旋转磁盘高了好几个数量级。

接口

接口是驱动器支持与系统通信的协议，一般通过一个磁盘控制器实现。有SCSI、SAS和SATA接口。

存储类型

存储可以通过多种方式提供给服务器使用。有四中通用架构：磁盘设备、RAID、存储阵列和网络连接存储。

方法

下表描述了磁盘 I/O 分析和调优的多种方法与实践。

方法	类型
工具法	观察分析
USE法	观察分析
性能监控	观察分析，容量规划
负载特征归纳	观察分析，容量规划
延时分析	观察分析
事件跟踪	观察分析
静态性能调优	观察分析，容量规划
缓存调优	观察分析，调优
资源控制	调优
微基准测试	实验分析
伸缩	容量规划，调优

这些方法可以单独或者结合使用。调查磁盘问题时，建议是按以下顺序使用这些策略：USE方法、性能监控、负载特征归纳、延时分析、微基准测试、静态分析和事件跟踪。

工具法

工具法是一套流程，使用所有可用的工具，检查它们提供的关键指标。方法固然简单，但还是有因工具提供数据的限制而忽略一些问题的可能，而且可能需要花费大量的时间。

对于磁盘，工具法可能包括检查以下工具：

• iostat：使用扩展模式寻找繁忙磁盘（超过60%使用率），较高的拼接服务时间（超过大概10ms），以及高IOPS（可能）。
• iotop：发现哪个进程引发了磁盘I/O。
• dtrace/stap/perf：包含了 iosnoop(1) 工具，仔细检查磁盘 I/O 延时，以发现延时离群点（超过大概 100ms）
• 磁盘控制器专用工具（厂商提供）

USE 方法

USE 方法在早期性能调查时，在所有组件内发现瓶颈和错误。下面描述如何在磁盘设备和控制器上适用USE方法。

磁盘设备

检查每个磁盘设备的如下指标：

• 使用率：设备忙碌时间
• 饱和度：I/O 在队列里等待的程度
• 错误：设备错误

第一个要检查的是错误。它们可能由于系统工作正常而被忽略——只是慢多了——但磁盘失效了：一般磁盘配置在一个能够容忍失效的冗余盘阵里。与操作系统里看到的标准磁盘错误计数器不同，磁盘驱动器支持更多种类的错误计数器，并且可以通过特殊工具查看。

如果磁盘设备是物理磁盘，使用率就很直白了。如果是虚拟磁盘，使用率可能并不直接反映底下物理磁盘的实际情况。

磁盘控制器

对于每个磁盘控制器，检查如下指标：

• 使用率：当前值对比最大吞吐量，对操作频率也做同样的比较
• 饱和度：由于控制器饱和造成的I/O等待程度
• 错误：控制器错误

这里的使用指标不是用时间定义的，而是使用了磁盘控制器卡的上限：吞吐量（每秒字节数）和操作频率（每秒操作数）。操作包括了读/写以及其他的磁盘命令。吞吐量和操作频率也可能受限于磁盘控制器和系统之间的传输，以及磁盘控制器和每块磁盘之间的传输总线。每个传输总线都需要进行同样的检查：错误、使用率、饱和度。

性能监控

性能监控可以发现一段时间内存在的问题和行为的模式。重要的磁盘I/O 指标如下：

• 磁盘使用率
• 响应时间

数秒内 100%磁盘使用率可能意味着问题。超过60%的使用率可能就会因为不断增长的队列而导致糟糕的性能，具体取决于实际的环境。

响应时间的增长对性能产生了影响，其背后可能是由于不断变化的负载或者新的竞争负载的加入。至于负载是”正常“还是”有害“，取决于我们的负载本身、环境和延时需求。如果不确定，那可以做一次微基准测试，对已知好的和差的负载做一个比较，对不相应的响应时间。

这些指标应该按磁盘分布检查，以找到不平衡的负载和个体性能很糟糕的磁盘。可以按照每秒平均值监控响应时间指标，另外还包括其他数据列，如最大值和标准差。理想情况下，最好检查响应时间的全分布，比如使用直方图或者热图，以发现延时离群点和其他模式。

如果系统实施了磁盘I/O 资源流控，那么还可以收集一些关于是否以及何时实施流控统计信息。磁盘 I/O 瓶颈有可能是流控限制的结果，而不是磁盘自身活动的缘故、

使用率和响应时间揭示了磁盘性能的结果。还可以加入更多的指标以刻画负载特征，包括IOPS和吞吐量，这些都给容量规划提供了重要的数据来源。

负载特征归纳

归纳负载特征是容量规划、基准测试和模拟负载当作的一项重要活动。通过发现并排查不需要的工作，它有可能带来最多的性能收益。

下面是用来刻画磁盘 I/O 负载的几项基本特征，这些数据放在一起，能够画出磁盘工作任务的一个大致模样：

1. I/O 频率
2. I/O 吞吐量
3. I/O 大小
4. 随机和连续比例
5. 读写比

高级负载特征归纳/检查清单

归纳负载特征还可能需要包括其他一些细节信息。可以考虑下面列出的这些项目，在深度研究磁盘问题时可以用来做检查清单。

• 系统 IOPS是多少？每个磁盘呢？每个控制器呢？
• 系统吞吐量是多少？每个磁盘呢？每个控制器呢？
• 哪个应用程序或者用户正在使用磁盘？
• 哪个文件系统或者文件正在被访问？
• 碰到什么错误了吗？这些错误是源于非法请求，还是磁盘问题？
• I/O 在可用磁盘之间均衡吗？
• 每条参与的传输总线上的IOPS是多少？
• 每条参与的传输总线上的吞吐量是多少？
• 发出了哪些非数据传输磁盘命令？
• 为什么发起磁盘I/O（内核调用路径）？
• 磁盘I/O 里应用程序同步的调用占多少？
• I/O 到达时间的分布是什么样的？

性能特征归纳

与负载特征归纳相比，下面的问题归纳了负载产生的性能特征：

• 每块盘有多忙（使用率）？
• 每块盘的 I/O 饱和度是多少（等待队列）？
• 平均 I/O 服务时间是多少？
• 平均 I/O 等待时间是多少？
• 是否存在高延时的 I/O 离群点？
• I/O 延时的全分布是什么样的？
• 是否有例如 I/O 流控的系统资源控制，存在并且激活了吗？
• 非数据传输磁盘命令的延时是多少？

延时分析

延时分析需要深度研究系统以发现延时的来源。在设计磁盘的情况下，调查一般止于磁盘接口这一层：发起 I/O 请求和完成中断之间的时间。如果这个时间与应用程序感受到的 I/O 延时一致，通常可以安全地推断出 I/O 延时源于磁盘，这样就可以专心调查其中的原因。如果延时有所不同，则需要从操作系统软件栈里的其他层出发，找到其来源。

下图描绘了 I/O 栈，已经两个 I/O 离群点A和B在不同层的延时状况。

I/O A的延时从应用程序到底下的磁盘驱动都差不多。这个状况直接把延时的矛头指向了磁盘（或者磁盘驱动）。如果对每一层都单独进行测量，从每层之间基本相同的延时就可以推断出这个结论。

B的延时看上去来自文件系统层（锁或者队列？），因为底层的I/O 延时只占了较小的部分。需要注意的是，不同软件栈可能会放大或者缩小 I/O，这意味着 I/O的大小、数量和延时在相邻层之间会有所不同。

每层的延时可以被表示如下：

• 单位时间I/O 平均值：一般由操作系统工具报告。
• I/O全分布：通过直方图或者热图表示。
• 单位I/O 延时值
  

事件跟踪

事件跟踪指的是每个 I/O 事件的信息都被跟踪并分布记录在案。对于观察分析方法而言，这是最后的手段。由于捕捉和保存这些信息的缘故，它增加了一些性能开销。这些信息通常写入日志文件以供日后分析。对于每个I/O，日志文件应该至少包括以下信息。

• 磁盘设备 ID。
• I/O 类型：读或写。
• I/O 偏移量：磁盘位置。
• I/O 大小：字节数。
• I/O 请求时间戳：I/O 发到设备的完成时间（也称为I/O策略）。
• I/O 完成时间戳：I/O 事件完成的时间（完成中断）。
• I/O 完成状态：错误。

其他信息还可能包括（如果有的话）、PID、UID、应用程序名称、文件名和所有非数据传输命令的事件。

根据 I/O 请求时间戳和完成时间戳可以计算出磁盘I/O 延时。在阅读日志时，单独排序每一项很有帮助——可以看到磁盘 I/O 是如何被设备重新排序的。到达的分布也可以从时间戳里看出来。

由于磁盘 I/O 是分析大热门，常常有静态跟踪点可以加以利用，用来跟踪请求和完成。另外，还可以使用动态跟踪进行高级分析，并捕捉下面这写类似的跟踪日志：

• 块设备驱动I/O
• 接口驱动命令（例如sb）
• 磁盘设备驱动命令

命令包括读/写以及非数据传输命令。

静态性能调优

静态性能调优主要关注配置环境的问题。对于磁盘性能，检查下列方面的静态配置：

• 现在有多少块盘？是什么类型？
• 磁盘固件是什么版本？
• 有多少个磁盘控制器？接口类型是什么？
• 磁盘控制器卡是查到高速插槽上的吗？
• 磁盘控制器的固件是什么版本？
• 配置了RAID了吗？是怎么配置的，包括条带宽度？
• 多路径是否可用并配置了吗？
• 磁盘设备驱动是什么版本？
• 存储设备驱动有什么操作系统的缺陷/补丁？
• 磁盘 I/O 有资源控制吗？

主要性能缺陷可能存在于设备驱动和固件当前，最好使用厂商提供的更新修复。

回答这些问题能够暴露一些被忽视的配置问题。有时按照了某种负载来配置文件系统，但后来却用再了其他场景里。这个方法能让我们重新审视那些配置选项。

缓存调优

系统里可能存在多种不同的缓存，包括应用程序、文件系统、磁盘控制器和磁盘自己。总体上来说，先检查有哪些缓存，接着看它们是否投入使用、使用的情况如何、缓存大小，然后根据缓存调整负载，根据负载调整缓存。

资源控制

操作系统可能会提供一些控制方法，把磁盘 I/O 资源分配给一些或者几组进程。控制可能包括固定极限IOPS 和吞吐量，或者通过更加灵活的方式共享资源。

微基准测试

微基准测试的测试参数如下：

• 方向：读或写
• 磁盘偏移量模式：随机或连续
• I/O 大小：512B ~ 1MB
• 并发度：同时发起的I/O 数量，或者执行 I/O 的线程数
• 设备数量：单块测试，或者多块磁盘（以得到控制器和总线限制）

磁盘

可以使用下面建议的负载执行微基准测试，以得出单块磁盘的相应数据：

• 最大磁盘吞吐量（MB/s）：128KB读，连续
• 最大磁盘操作频率（IOPS）：512B读，仅对偏移量 0。
• 最大磁盘随机读（IOPS）：512B读，随机偏移量。
• 读延时剖析（平均毫秒数）：连续读，按照512B、1KB、2KB、4KB 重复测试。
• 随机 I/O 延时剖析（平均毫秒数）：512B读，按照全地址扫描，指定开始地址区间，指定结束地址区间重复测试。

这些测试同样可以针对写操作重做一遍。使用“偏移量 0” 使数据缓存在磁盘缓存中，这样能够测量缓存的访问时间。

磁盘控制器

磁盘控制器可以通过对多块磁盘施加负载，执行基准测试，达到控制器的极限。可以使用下列的测试，并对磁盘施加如下建议的负载。

• 最大控制器吞吐量（MB/s）：128KB，仅对 0 地址。
• 最大控制器操作频率（IOPS）：512B 读，仅对 0 地址。

可以一个个地施加负载，并注意极限。要找到一个磁盘控制器的极限可能需要超过一打的磁盘。

伸缩

磁盘和磁盘控制器有吞吐量和 IOPS 极限，并可以通过微基准测试方法得出。调优方法最多把性能提高到这些极限。如果还需要更多的磁盘性能，并且其他方法（例如缓存）不起作用，磁盘就需要伸缩。

下面是一个简单的基于资源的容量规划方法：

1. 确定目标磁盘负载的吞吐量和IOPS。如果系统已经有负载运行，使用当前磁盘吞吐量和IOPS 来表示用户数量，然后把这些数字放大到目标数量。
2. 计算支撑这个负载需要的磁盘数量。记得考虑RAID配置。不要使用单位磁盘最大的吞吐量和IOPS数值，因为这会得出一个100% 磁盘使用率的计划，而导致马上会有因饱和排队带来的性能问题。定下目标使用率（如50%），然后按比例伸缩。
3. 计算支撑这个负载需要的磁盘控制器数量。
4. 检查未超过传输的极限，并按需伸缩传输线。
5. 计算单位磁盘I/O 的CPU周期数，以及需要的CPU数量。

用哪一个最大单位磁盘吞吐量和IOPS数值取决于它们的类型和磁盘类型。可以使用微基准测试来找到给定I/O 大小和I/O 类型的特定极限，还能对当前负载使用负载特征归纳方法以发现最重要的大小和类型。

要达到磁盘负载需求，一般的情况是服务器需要连接相当多的磁盘，而这些磁盘通过存储阵列连接。我们以前常说，“加更多的转轴”。现在我们可能要说，“加更多的闪存”。

分析

下表介绍了基于磁盘 I/O 性能分析工具：

Linux	描述
iostat	各种单个磁盘统计信息
sar	磁盘历史统计信息
pidstat, iotop	按进程列出磁盘 I/O 使用情况
blktrace	磁盘 I/O 事件跟踪
DTrace	自定义静态和动态跟踪
MegaCli	LSI 控制器统计信息
smartctl	磁盘控制器统计信息

欢迎扫码关注V信公众号一起交流：一苦四甜