我有一个24核心机器，运行Ubuntu服务器10.04的94.6GiB RAM。 不同于另一台运行相同types和数量进程的服务器（4个内核），这个盒子的iowait值很高。 两台计算机都通过4个FC卡连接到VNX Raid文件服务器，24核计算机，另一台通过2个千兆以太网卡连接。 四核机器目前优于24核机器，具有较高的CPU使用率和较低的艾默生特性。
在9天的正常运行时间内，爱荷华州的平均值为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？ 这是正常的吗？
更新：
networking连接和VNX读/写容量已被排除为瓶颈。 我们可以使用4个绑定的网卡（循环）来达到800MB / s的速度。 光纤通道卡尚未使用。 VNX能够很好地处理IO（两个池（总共60个磁盘）中每个池的RAID6,30x2TB 7.2kRPM磁盘，读取率大约为60％）。
忽略大约dm和sdc，它们都是内部磁盘，而不是问题的一部分。
我们认为这个问题可能是由nfs挂载或TCP（我们有5个挂载到VNX上的5个分区），但不知道到底是什么。 任何build议？
首先，如果你的CPU（和该死的！这是24）吃数据比提供数据存储的速度更快，那么你得到的iowait。 这是内核在阻塞io期间暂停进程（读取速度太慢或同步写入）的原因。
因此请检查存储器是否能够为24个内核提供足够的吞吐量。
举例来说，假设您的存储器可以提供500MB / s的吞吐量，通过2千兆以太网线（bond）连接，networking已经将最大吞吐量限制在100-180 MB / s左右。 如果您的进程以50 MB / s的速度吃掉数据，并且在4核心机器上运行4个线程：4 x 50 MB / s = 200 MB / s。 如果networking可以维持180MB / s，那么你没有太多的延迟，你的CPU将被加载。 这里的networking是一个小瓶颈。
现在，如果将这个扩展到24个内核和24个线程，那么即使您改变布线来达到这样的吞吐量，您的存储系统也不会提供超过500 MB / s的速度，但仍然需要1200 MB / s，这成为了一个瓶颈。
谈到等待，瓶颈可能无处不在。 不仅在物理层上，而且在软件和内核空间缓冲区中。 这实际上取决于使用模式。 但是由于软件瓶颈更难以识别，因此在调查软件堆栈之前，通常最好检查硬件上的理论吞吐量。
如上所述，当进程进行读取并且数据需要时间到达时，或者当进行同步写入并且数据修改确认需要时间时，发生iowait。 在同步写入过程中，进程进入不可中断的睡眠，所以数据不会被破坏。 有一个方便的工具可以查看哪个调用使进程挂起： latencytop 。 这不是唯一的，但你可以试一试。
注意：为了您的信息，dm代表设备映射器而不是数据移动器。
首先，这是很多铁的圣地狱！ 🙂
不幸的是，由于你的设置听起来非常复杂，我不认为任何人都可以提供一个“你的问题！ 回答，除非他们已经做了一些非常相似或相同的设置，并遇到同样的问题。 所以，当这个文本被SU标记为“答案”时，你应该把它看作更像是一个“build议”。 我不能把它放在评论中，因为它太多了。 ：S
如果不知道硬件如何映射到设备，那么很难说I / O为什么会在一个地方而不是另一个地方。 你如何装置设备？ 您的程序是直接访问sd*设备，还是将所有的文件系统安装在dm设备上，并通过那里进行所有文件访问？
其他的事情，我不得不问：
它是什么样的RAID？ 如果你用RAID5或者RAID6来计算奇偶校验位，希望Raid服务器硬件能够处理这些奇偶校验位……如果不是，处理服务器正在这么做……这是次优的，并且可能导致I / O延迟用软件完成。
您隔离了消息中两台服务器之间的主要区别之一。 一个是使用光纤通道，一个是使用以太网。 光纤通道应该提供更好的延迟和带宽，但也许这也是一个问题：如果它提供了大量的吞吐量，它可能使RAID服务器本身非常忙碌……拥塞导致缓冲区/caching填满，这增加延迟，导致更高的I / O等待。
这就好像你的磁盘arrays可能有一个缓冲区膨胀问题 – 你知道吗？ 硬件RAID控制器通常拥有大量的板载caching，不是吗？ 所以，当媒体的I / O被排队，caching满了脏页面，最终整个事情是饱和的（如果机械存储无法跟上负载）和延迟航行在屋顶…肯定你可以用24核+ FC产生比4核+ GbE更多的负载:)检查RAID服务器，看看磁盘有多忙……很多“I / O”可能只是控制包等。我不确定FC是如何工作的，但是如果它像TCP一样，那么如果延迟太高，你将会看到重新传输。
就像如果你通过电话问别人一个问题，而他们不回答几秒钟，你会说“你好？ – networking协议（FC只是一个networking协议）只是在一个较短的时间内完成同样的事情。 但当然那额外的“你好？” 在networking环境中是昂贵的，因为它增加了更多的数据到已经拥挤的pipe道。
最后，一个小提示：
在debugging延迟/ IO等待/吞吐量问题时，请始终测量 。 到处测量。 测量电线，测量程序本身在做什么，在处理结束时测量，在RAID服务器上测量等。不要只从一个angular度来看待它 – 尝试考虑系统中的每个单独的组件负责处理，读取或写入pipe道中的任何数据。 拆分一个事务或一个离散的工作单元，并精确地parsing通过您的硬件所采取的path，并在每个不同的组件上测量，看看是否有瓶颈或地方存在过度的延迟等。我的一个朋友称之为“剥皮回到洋葱“，我从此使用这个词来指代debugging数据stream的任务。
一小部分。 在这种情况下，您可能需要查看块级调优和I / O调度程序。 我对Ubuntu并不熟悉，但是有很多的存储性能调整。 这在SAN存储和数据库的情况下绝对适用。
nobarrier重新安装你的文件系统。 （ 提示Ubuntu ） 一些相关的服务器故障链接
Linux – 真实世界的硬件RAID控制器调优（scsi和cciss）
感谢所有的想法和意见。 该问题与非最佳以太网绑定configuration的组合相关，与VNX本身的缺陷I / O模块相结合。 I / O速率现在接近我们所期望的。 有趣的是，dd文件写入和阅读testing以及iozone基准testing无法检测到这一点，读写速度几乎与预期的一样快。
我会尽快编辑更多的信息，但首先我想说，你不应该让iostat的dm- *输出混淆你。 设备映射器是一个内核通路设备，就像md *（md0，md1等），所以你真的只关心你的底层设备。 所有传递到磁盘的数据都是通过dm / md传递的，而实际的总数（字节数，秒数等）是准确的，但这个util是误导性的。
此外，这是一个非常大的内存。 有趣的事情开始发生那么高（我自己运行2x64s和2x96s），特别是如果你有一个进程占据了一半以上的内存。 阅读这篇文章的更多信息 。 文章提到MySQL，但请注意，它不是特定于MySQL。 每个软件进程都会对另一个物理处理器的访问内存产生惩罚 – 比如说48GB属于一个进程，48进程到另一个进程。 这个进程只能属于一个进程，为了到达另一个进程（在自己的48GB已经用完之后），它必须决定将它的一部分存储在交换中，或者付出巨大的代价来进出其他proc的记忆。 文章build议运行numactl命令强制软件不交换，而是支付罚款。 我个人看到这方面的巨大进步。 换句话说 – 检查一下你的I / O是否要交换！ 使用免费-m（或类似的）。 如果你有足够的可用内存，但有一些不平凡的交换量（比如10％），这可能是你的问题。
从存储angular度来看，你有没有办法测量scsi延迟？ OS Io的等待时间包括了存储控制之外的一堆东西，但是当我进入存储盒并在2ms处看到IO延迟时，我知道无论服务器在内部获得什么，scsi命令都会被响应很快，我可以消除存储作为一个variables。