带有数据移动器的Linux I / O瓶颈

我有一台具有94.6GiB RAM的24核计算机，该计算机运行Ubuntu服务器10.04。与其他服务器（具有4个内核）运行相同类型和数量的进程的服务器不同，此设备正在经历较高的％iowait。两台计算机均通过4个FC卡连接到VNX Raid文件服务器，24核计算机，另一台通过2 GB以太网卡连接。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，这将成为瓶颈。

当涉及到等待时，瓶颈无处不在。不仅在物理层，而且在软件和内核空间缓冲区。这实际上取决于使用模式。但是由于很难识别软件瓶颈，因此通常更可取的是在研究软件堆栈之前检查硬件的理论吞吐量。

如上所述，当进程进行读取并且数据花费时间到达时，或者当它进行同步写入并且数据修改确认花费时间时，就会发生iowait。在同步写入期间，该进程将进入不间断的睡眠状态，因此数据不会被破坏。有一个方便的工具来查看哪个调用使进程挂起：latencytop。它不是唯一的一种，但是您可以尝试一下。

注意：仅供参考，dm代表设备映射器而不是数据移动器。

首先，神圣的地狱有很多铁！:)

不幸的是，由于您的设置听起来很复杂，所以我认为没有人能够直接提供“这是您的问题！” 答案，除非他们用非常相似或完全相同的设置完成某件事并且遇到相同的问题。因此，尽管该文本被SU标记为“答案”，但您可能应该将其更像是“建议”。我不能在评论中加上它，因为它的词太多了。：S

在不知道硬件如何映射到设备的情况下，很难说出为什么I / O流向一个地方而不是另一个地方。您如何安装设备？您的程序是sd*直接访问设备，还是所有文件系统都安装在dm设备上并且所有文件访问都通过设备进行？

我不得不问的其他事情：

• 它是哪种RAID？如果您正在使用RAID5或RAID6计算奇偶校验位，则希望由RAID服务器硬件来处理...如果不是，则处理服务器正在这样做....用软件完成。

• 您在邮件中隔离了两个服务器之间的主要区别之一。一种是使用光纤通道，另一种是使用以太网。光纤通道应该提供更好的延迟和带宽，但这也许也是一个问题：如果它提供大量吞吐量，可能会使RAID服务器本身变得非常繁忙……并且拥塞导致缓冲区/缓存填满，这增加延迟，这会导致更高的I / O等待时间。

几乎就像磁盘阵列可能出现缓冲区膨胀问题一样-您知道吗？硬件RAID控制器通常具有大量的板载缓存，不是吗？因此，随着对媒体的I / O排队，而高速缓存中充满了脏页，最终整个事情就变得饱和了（如果机械存储无法跟上负载的话），并且等待时间在屋顶飞速发展……您可以使用24核+ FC而不是4核+ GbE产生更多的负载：）检查RAID服务器，看看磁盘有多忙...很多“ I / O”可能只是控制数据包，等等。我不确定FC如何工作，但是如果它像TCP之类的东西，那么如果延迟太高，您将看到重传。

就像您通过电话问某人一个问题，而他们几秒钟不回答时，您说“你好？” -网络协议（FC只是网络协议）在较短的时间内完成了相同的操作。但是，当然还有额外的“你好？” 在网络环境中成本很高，因为它将更多的数据添加到已经拥塞的管道中。

最后，一般提示：

调试延迟/ IO等待/吞吐量问题时，请务必进行测量。到处测量。进行在线测量，测量程序本身在做什么，在处理端进行测量，在RAID服务器上进行测量等。不要仅仅从一个角度来看它-尝试考虑系统中每个单独的组件负责处理，读取或写入管道中的任何数据。拆掉一个事务或一个离散的工作单元，并精确地剖析它在硬件中所经过的路径，并在每个不同的组件上进行测量，以查看是否存在瓶颈或存在不必要的延迟的地方，等等。 ”，从那以后，我就一直使用该短语来指代调试数据流的任务。

一个小的补充。在这种情况下，您可能需要查看块级调整和I / O调度程序。我对Ubuntu不太熟悉，但是有很多存储性能旋钮需要调整。这绝对适用于SAN存储和数据库。

• 看一下系统I / O调度程序。CFQ是默认设置，但noop和最后期限是数据库工作负载的常见选择。
• 请参阅此链接，以获得其他可能有用的调整参数。
• 您提到了NFS和块存储。如果阻塞，则使用哪个文件系统？从这里开始，I / O等待听起来像是写阻塞情况。是否启用写屏障？使用重新挂载文件系统nobarrier。（对于Ubuntu的提示）

一些相关的服务器故障链接...

Linux-实际硬件RAID控制器调整（scsi和cciss）

感谢所有的想法和意见。该问题与非最佳以太网绑定配置的结合以及VNX本身上的有缺陷的I / O模块有关。现在，I / O速率接近我们的预期。有趣的是，dd文件的写入和读取测试以及iozone基准测试无法检测到这一点，并且读取和写入的速度几乎与预期的一样。

我将尽快编辑更多信息，但首先我想说的是，您不应该让iostat的dm- *输出使您感到困惑。就像md *（md0，md1等）一样，Device-mapper是一个内核通过设备，因此您实际上只关心底层设备。所有传递到磁盘的数据都将经过dm / md，并且实际的总数（字节，秒等）是准确的，但是实用程序会产生误导。

另外，那是非常大的内存。有趣的事情开始发生得很高（我自己运行2x64s和2x96s），尤其是如果您有一个进程占用了一半以上的内存。阅读本文以获得更多信息。本文提到了mysql，但请注意它不是特定于mysql。每个软件进程都会对另一个物理处理器的访问内存产生惩罚-认为48GB属于一个进程，而48GB属于另一个进程。该进程只能属于一个proc，为了到达另一个proc的内存（在其自身的48GB用完之后），它必须决定将其中的48个存储在交换中，或者付出巨大的代价才能进入和退出其他进程的内存。本文建议运行numactl命令来强制软件不进行交换而代之以罚款。我个人从中看到了巨大的进步。换句话说-检查一下您的某些I / O是否要交换！为此使用free -m（或类似的）。如果您有足够的可用内存，但是交换量很少（例如超过10％），这很可能是您的问题。

从存储角度看，您是否有办法测量scsi延迟？OS io等待时间包括存储控制之外的一堆东西，但是当我进入存储盒并看到2ms的IO延迟时，我知道无论服务器内部是什么，都会响应scsi命令快速，并且我可以消除存储作为变量。