我的CPU I / O等待稳定在50％左右，但是运行iostat 1时显示几乎没有磁盘活动。

是什么原因导致没有等待而等待？

注意：这里没有NFS或FUSE文件系统，但是它使用的是Xen虚拟化。

NFS可以做到这一点，如果其他网络文件系统（甚至是基于FUSE的设备）具有类似的效果，也不会令我感到惊讶。

服务器上的其他VM是否有可能损坏磁盘？

我知道通过虚拟化，如果主机节点过载，您会得到一些奇怪的结果。

如果这是使用基于实例的存储的Amazon EC2 Xen环境，请要求Amazon检查包含该映像的主机的运行状况。

如果这是一个Xen环境，您可以访问虚拟机管理程序，则从那里检查IOwait，以查看用于xvda和xvdb设备的磁盘映像（文件，网络，LVM切片等）。通常，您还需要检查I / O系统中的管理程序，因为其他磁盘设备可能会垄断系统的资源。

iostat -txk 5

通常是一个很好的启动诊断工具。对于所有可用设备，它需要5秒钟的I / O汇总，因此在导入和退出VM映像时都非常有用。

检查可用的文件描述符/索引节点。当您达到极限时，他们交换并模仿iowait

编辑

我看到您正在使用xen，看看您当前的中断，您可能会发现blkif高于正常水平。

现在有点晚了，但是安装munin确实可以帮助将来进行调试。

sudo sysctl vm.block_dump=1

然后检查dmesg以查看正在执行块读取/写入或弄脏inode的操作。

还要检查limits.conf中的nofile limit，一个进程可能请求的文件数量超过了允许打开的文件数量。

警告：HDPARM很危险，请始终阅读要使用的命令！

如果没有其他虚拟机向硬盘施加压力，请执行

hdparm -f

在基础物理磁盘上。可能是磁盘缓存无法正常工作。这将刷新存储在高速缓存中的数据，并且您可以不断监视I / O，在刷新后它是否将再次上升。如果是，则将是缓存问题。

通过平均负载，我看到阻塞的网络操作（即，对外部数据库服务器的长时间调用）增加了。我不确定，但我猜网络IO会导致CPU等待时间增加？谁能确认？

可能是环回设备，它们本身通过网络安装。

在我的机器上，NFS是最大的IO-WAIT“生产者”。我的笔记本电脑中有一个固态硬盘，它的运行速度可真快，因此“真正的IO”不是问题。但是，由于安装了nfs共享，有时我有很多IO等待。

SCP有时似乎也导致IO等待，但扩展幅度较小。

这可以是任何东西。这只是意味着某些东西正在等待I / O操作的结束。您可以通过ps找出它是什么进程，然后将gdb附加到它上并检查backtrace以确定哪个调用被挂起（通常这是一些与网络相关的东西或突然断开的磁盘）。有关fd的信息，请查看/ proc。

在RAID中的磁盘出现故障并且其中的一些SATA电缆弯曲严重之前，我也遇到了类似的问题。

CPU使用率接近0％，但是4核系统上的1个或更多CPU在IOwait中花费了100％的时间来长时间（通过top多行cpu显示），而IOps和带宽却很低（发现通过iostat），但突发性高中断活动。在任何磁盘访问期间（例如，从某人的emacs会话中自动保存），交互式命令行的使用都是痛苦的，但是在IOwait周期过去之后（并且在多次重试之后操作成功），这种方式是可以忍受的。