我有一台 24 核机器，内存为 94.6GiB，运行 Ubuntu 服务器 10.04。该框正在经历高 %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 holdup。
我可以查看哪些内容来帮助诊断问题？为什么所有数据都通过/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 wait，瓶颈无处不在。不仅在物理层上，而且在软件和内核空间缓冲区中。这实际上取决于使用模式。但由于软件瓶颈更难识别，通常最好在调查软件堆栈之前检查硬件的理论吞吐量。
如前所述，当进程进行读取并且数据需要时间到达时，或者当它进行同步写入并且数据修改确认需要时间时，就会发生 iowait。在同步写入期间，进程进入不可中断的睡眠状态，因此数据不会被破坏。有一个方便的工具可以查看哪个调用导致进程挂起：
latencytop. 它不是同类中唯一的一种，但您可以尝试一下。注意：供您参考，dm 代表设备映射器而不是数据移动器。
首先，神圣的地狱有很多铁！:)
不幸的是，由于您的设置听起来非常复杂，我认为没有人能够直接提供“这是您的问题！” 回答，除非他们用极其相似或相同的设置做了一些事情并遇到了同样的问题。因此，虽然 SU 将此文本标记为“答案”，但您可能应该将其视为更像是“建议”。而且我不能把它放在评论中，因为它太多了。:S
如果不了解您的硬件是如何映射到设备的，就很难说出为什么 I/O 会去一个地方而不去另一个地方。你如何安装这些设备？您的程序是
sd*直接访问设备，还是所有文件系统都安装在dm设备上并且所有文件访问都通过那里进行？我要问的其他事情：
它是什么样的RAID？如果您正在使用 RAID5 或 RAID6 计算奇偶校验位，则希望 raid 服务器硬件能够处理这些问题……如果没有，则处理服务器正在这样做……这是次优的，如果可能会导致 I/O 延迟在软件中完成。
您在消息中隔离了两个服务器之间的主要区别之一。一种使用光纤通道，一种使用以太网。光纤通道应该提供更好的延迟和带宽，但也许这也是一个问题：如果它提供了大量的吞吐量，它可能会使 RAID 服务器本身非常繁忙......并且拥塞导致缓冲区/缓存填满，这增加延迟，从而导致更高的 I/O 等待。
这几乎就好像您的磁盘阵列可能存在缓冲区膨胀问题——您知道吗？硬件 RAID 控制器通常有大量的板载缓存，不是吗？因此，当媒体的 I/O 排队并且缓存中充满脏页时，最终整个事情都会饱和（如果机械存储无法跟上负载）并且延迟会通过屋顶航行......当然与 4 核 + GbE 相比，24 核 + FC 可以产生更多负载 :) 检查 RAID 服务器，看看磁盘有多忙......很多“I/O”可能只是控制数据包等。我我不确定 FC 是如何工作的，但如果它类似于 TCP，那么如果延迟太高，您将看到重传。
就像你在电话里问某人一个问题，他们几秒钟都没有回答，你说“你好？” -- 网络协议（FC 只是一种网络协议）做同样的事情，只是在更短的时间范围内。但当然还有那个额外的“你好？” 在网络上下文中是昂贵的，因为它会向已经拥塞的管道添加更多数据。
最后，一般提示：
在调试延迟/IO 等待/吞吐量问题时，始终测量. 处处测量。在线路上测量，测量程序本身在做什么，在处理端测量，在 RAID 服务器上测量，等等。不要只从一个角度看它——尝试考虑系统的每个单独组件负责处理、读取或写入管道中的任何数据。拆开一个事务或一个离散的工作单元，并准确剖析它通过硬件的路径，并测量每个不同的组件，看看是否存在瓶颈或存在过度延迟的地方等。我的一个朋友称之为“剥离” back the onion”，从那以后我就一直使用这个短语来指代调试数据流的任务。
一个小小的补充。在这种情况下，您可能需要查看块级调整和 I/O 调度程序。我对 Ubuntu 不太熟悉，但是有很多存储性能旋钮可以调整。这绝对适用于 SAN 存储和数据库。
nobarrier. （Ubuntu 的提示）一些相关的服务器故障链接...
Linux - 现实世界的硬件 RAID 控制器调整（scsi 和 cciss）
感谢大家的想法和意见。该问题与非最佳以太网绑定配置以及 VNX 本身有缺陷的 I/O 模块有关。I/O 速率现在接近我们预期的水平。有趣的是，dd 文件写入和读取测试以及 iozone 基准测试无法检测到这一点，并且读取和写入的速度几乎与预期的一样快。
我会尽快编辑更多信息，但首先我想说你不应该让 iostat 的 dm-* 输出混淆你。Device-mapper 是内核中的直通设备，就像 md*（md0、md1 等）一样，因此您实际上只关心底层设备。传递到磁盘的所有数据在途中都经过 dm/md，实际总数（字节、秒等）是准确的，但实用程序具有误导性。
此外，这是一个非常大的内存量。有趣的事情开始发生那么高（我自己运行 2x64s 和 2x96s），特别是如果你有一个进程占用超过一半的 ram。阅读这篇文章了解更多信息。文章提到了 mysql 但请注意它不是mysql特有的。每个软件进程都会因访问另一个物理处理器的内存而受到惩罚——想想 48gb 属于一个进程，48gb 属于另一个进程。该进程只能属于一个进程，并且为了到达其他进程的内存（在它自己的 48GB 内存用完之后），它必须决定要么将它的 48GB 中的一些存储在交换中，要么付出巨大的代价来往返于其他进程的内存。文章建议运行 numactl 命令以强制软件不交换，而是支付罚款。我个人看到了由此带来的巨大改进。换句话说 - 检查您的某些 I/O 是否要交换！为此使用 free -m （或类似的）。如果您有足够的可用内存，但有一些不小的交换页（比如 10% 以上），这很可能是您的问题。
从存储的角度来看，您是否有衡量 scsi 延迟的方法？操作系统 io 等待时间包括存储控制之外的一堆东西，但是当我进入我的存储箱并看到 2ms 的 IO 延迟时，我知道无论服务器内部获取什么，都会响应 scsi 命令很快，我可以消除存储作为变量。