Ben*_*min 8 linux io bottleneck ubuntu-10.04
我有一台运行 Ubuntu 服务器 10.04 的 24 核机器，内存为 94.6GiB。该机器正在经历高 %iowait，这与我们拥有（4 个内核）运行相同类型和数量的进程的另一台服务器不同。两台机器都连接到 VNX Raid 文件服务器，24 核机器通过 4 个 FC 卡连接，另一台通过 2 个千兆以太网卡连接。4 核机器目前优于 24 核机器，具有更高的 CPU 使用率和更低的 %iowait。
在 9 天的正常运行时间中，%iowait 平均为 16%，通常高于 30%。大多数时候 CPU 使用率非常低，大约为 5%（由于 iowait 高）。有充足的空闲内存。
我不明白的一件事是为什么所有数据似乎都通过设备 sdc 而不是直接通过数据移动器：
avg-cpu: %user %nice %system %iowait %steal %idle
6.11 0.39 0.75 16.01 0.00 76.74
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.00 0.00 0.00 1232 0
sdb 0.00 0.00 0.00 2960 0
sdc 1.53 43.71 44.54 36726612 37425026
dm-0 0.43 27.69 0.32 23269498 268696
dm-1 1.00 1.86 7.74 1566234 6500432
dm-2 0.96 1.72 5.97 1442482 5014376
dm-3 0.49 9.57 0.18 8040490 153272
dm-4 0.00 0.00 0.00 1794 24
dm-5 0.00 0.00 0.00 296 0
另一个难题是任务经常进入不可中断的睡眠模式（顶部），这也可能是由于 io 阻塞。
我可以查看什么来帮助诊断问题？为什么所有数据都通过/dev/sdc？这是正常的吗？
更新：
网络连接和 VNX 读/写容量已被排除为瓶颈。我们可以使用 4 个绑定的 NIC（循环）达到 800MB/s 的速度。光纤通道卡尚未使用。VNX 能够很好地处理 IO（RAID6，两个池中每个池的 30x2TB 7.2kRPM 磁盘（总共 60 个磁盘），大约 60% 的读取）。
忽略上面的dm和sdc，它们都是内部磁盘，不是问题的一部分。
我们认为问题可能出在 nfs 挂载或 TCP（我们在 VNX 上有 5 个挂载到 5 个分区），但不知道究竟是什么。有什么建议吗？
首先，如果您的 CPU（该死！那是 24 个）处理数据的速度比提供数据存储的速度快，那么您将获得 iowait。那是内核在阻塞 io（读取速度太慢或同步写入）期间暂停进程的时候。
因此，请检查存储是否可以为 24 个内核提供足够的吞吐量。
例如，假设您的存储可以提供 500MB/s 的吞吐量，并且您通过 2 千兆位以太网线（绑定）连接，网络已经将最大吞吐量限制在 100-180 MB/s 左右。如果您的进程以 50 MB/s 的速度处理数据，并且您在 4 核机器上运行 4 个线程：4 x 50 MB/s = 200 MB/s 消耗。如果网络能够维持 180MB/s，那么您将不会有太多延迟并且您的 CPU 将被加载。这里的网络是一个小瓶颈。
现在，如果将其扩展到 24 个内核和 24 个线程，则需要 1200 MB/s，即使您更改接线以允许这样的吞吐量，您的存储系统也不会提供超过 500 MB/s，这将成为瓶颈。
说到 io 等待，瓶颈可能无处不在。不仅在物理层，而且在软件和内核空间缓冲区。这实际上取决于使用模式。但由于软件瓶颈更难识别，因此在调查软件堆栈之前，通常最好先检查硬件的理论吞吐量。
如上所述，当进程进行读取并且数据需要时间到达时，或者当它进行同步写入并且数据修改确认需要时间时，就会发生 iowait。在同步写入期间，进程进入不间断睡眠，因此数据不会被损坏。有一个方便的工具可以查看哪个调用使进程挂起：latencytop. 它不是唯一的同类产品，但您可以尝试一下。
注意：为了您的信息，dm 代表设备映射器而不是数据移动器。
首先，神圣的地狱，这是很多铁！:)
不幸的是，由于您的设置听起来非常复杂，我认为没有人能够直接提供“这是您的问题！” 回答，除非他们用极其相似或相同的设置做了一些事情并遇到了同样的问题。因此，虽然此文本被 SU 标记为“答案”，但您可能更应该将其视为“建议”。而且我不能把它放在评论中，因为它的字太多了。:S
如果不了解您的硬件如何映射到设备，就很难说为什么 I/O 会去一个地方而不是另一个地方。你是如何安装设备的？您的程序是sd*直接访问设备，还是所有文件系统都安装在dm设备上并且所有文件访问都通过那里进行？
我要问的其他事情：
它是一种什么样的RAID？如果您使用 RAID5 或 RAID6 计算奇偶校验位，则希望由 RAID 服务器硬件处理...如果不是，处理服务器正在这样做....在软件中完成。
您在邮件中隔离了两个服务器之间的主要差异之一。一种是使用光纤通道，一种是使用以太网。光纤通道应该提供更好的延迟和带宽，但也许这也是一个问题：如果它提供大量吞吐量，它可能会使 RAID 服务器本身非常繁忙......并且拥塞导致缓冲区/缓存填满，这增加延迟，从而导致更高的 I/O 等待。
就好像您的磁盘阵列可能存在缓冲区膨胀问题一样——您知道吗？硬件 RAID 控制器通常有大量的板载缓存，不是吗？因此，当媒体的 I/O 排队并且缓存中充满脏页时，最终整个事情都饱和了（如果机械存储跟不上负载）并且延迟会飙升……当然与 4 核 + GbE 相比，24 核 + FC 可以产生更多负载:) 检查 RAID 服务器，看看磁盘有多忙……很多“I/O”可能只是控制数据包等。我不确定 FC 是如何工作的，但如果它类似于 TCP，那么如果延迟太高，您将看到重传。
就像如果你通过电话问某人一个问题而他们几秒钟没有回答，你说“你好？” -- 网络协议（而 FC 只是一个网络协议）做同样的事情，只是在更短的时间范围内。但当然，额外的“你好？” 在网络环境中是昂贵的，因为它向已经拥塞的管道添加了更多数据。
最后，一个一般提示：
在调试延迟/IO 等待/吞吐量问题时，请始终测量. 到处测量。在线路上测量，测量程序本身在做什么，在处理端测量，在 RAID 服务器上测量，等等。不要只从一个角度看——试着考虑系统的每个单独组件负责处理、读取或写入管道中的任何数据。拆开一个事务或一个离散的工作单元，准确剖析它通过硬件的路径，并在每个不同的组件上进行测量，看看是否存在瓶颈或存在过度延迟的地方等。我的一个朋友称之为“剥离”支持洋葱”，从那时起我就使用这个短语来指代调试数据流的任务。
感谢大家的想法和意见。该问题与非最佳以太网绑定配置以及 VNX 本身有缺陷的 I/O 模块的组合有关。I/O 速率现在接近我们的预期。有趣的是，dd 文件写入和读取测试以及 iozone 基准测试无法检测到这一点，并且读取和写入的速度几乎与预期一样快。