在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个分区),但不知道到底是什么.任何建议？
解决方法
因此,请检查存储是否可以为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代表设备映射器而不是数据移动器.
