☰

测试生产硬盘/调试高 I/O 负载

tag-icon • tag-icon linux redhat hardware hard-drive io
测试生产硬盘/调试高 I/O 负载

最近，这台服务器的负载非常高，超出了系统容量的应有水平。似乎使用磁盘进行最简单的操作（例如 YUM 更新）就能在 10LA 下使驱动器达到峰值，而运行速度远低于 1。

这可能是一次糟糕的驾驶吗？

iostat -xdk 1 50 http://pastebin.com/hRxY50FC

答案1

问题发生时，您可以发布 iostat -xdk 1 50 吗？请参阅 iostat 的手册页，了解可以使用什么开关来列出分区名称）。将其与同时获取的 top poutput 一起粘贴到 Pastebin 中。

好的，所以当您的磁盘在工作负载的某些时候似乎变得负载过重时。

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz       await  svctm  %util
sda              85.00     5.00  249.00   11.00  6040.00    64.00    46.95    10.73       44.23   3.85 100.00
sda               3.00     0.00  275.00    0.00  7764.00     0.00    56.47     7.63   23.27   3.64 100.00
sda             125.00    29.00  221.00    3.00  5508.00   128.00    50.32     7.49   41.08   4.46 100.00
sda              14.00    65.00  224.00   28.00  5940.00   372.00    50.10     1.97    8.05   3.52  88.80

与其他迭代相比，读取请求有时会变得太大。然后 await 增加。但是，avgqu-sz 中记录的平均队列大小仍然很低。这意味着，大部分 await 时间都花在存储服务请求上。它不在 Linux 端，我的意思是不在调度程序端。

粗略地说，有两个队列。一个在调度程序中，另一个在硬件方面。等待时间是根据每个 IO 从到达 IO 调度程序到由存储（即磁盘）提供服务的时间测量的。avgqu-sz 是 IO 调度程序和存储 lun 队列中包含的平均 IO 数。如果 avgqu-sz 远小于存储的队列深度，则意味着在调度程序队列中花费的时间很少。调度程序会将这些 IO 传递给存储，直到它们由存储提供服务，等待时间将持续增加。

长话短说，在我看来，在特定时间，存储会变得很慢，从而增加延迟。

答案2

除了原始磁盘容量之外，了解高磁盘利用率的一个重要问题是内存在系统中的运行情况。

良好的文件 IO 通常依赖于大量缓存。内存压力下可能发生两种情况，从而导致高 IO 负载：

  1. 缓存的文件将从内存中推送出来，为进程内存腾出空间（可以通过查看命令的输出来free查看
  2. 你可能会开始增加记忆力积极交换分区的进出。您可以使用以下命令查看交换分区下的 bi/bo，以了解是否发生这种情况vmstat。

如果一切看起来都不错，你可能需要研究一下确定哪个进程导致磁盘 I/O 负担过重？

相关内容