做一个top检查io等待，我得到这些数字：
Cpu(s): 6.7%us, 1.4%sy, 1.2%ni, 85.5%id, 5.0%wa, 0.0%hi, 0.3%si, 0.0%st
看这些数字（％us〜=％wa），是否意味着：
评估这些数字时需要小心。
在这种情况下，IOWait是衡量一段时间内CPU（或所有CPUS）闲置的时间，因为所有可运行的任务都在等待IO操作的完成。
在你的例子中，如果你有20个CPU，并且有一个任务确实敲击了磁盘，那么这个任务（实际上）将100％的时间花在IOWait上，随后运行这个任务的CPU花费几乎100％的时间IOWAIT。 但是，如果其他19个CPU处于空闲状态而不使用此磁盘，则会报告0％IOWait。 这导致平均IOWait百分比为5％，事实上，如果您要查看磁盘利用率，则可能会报告100％。 如果在磁盘上等待的应用程序对您至关重要 – 这5％是有点误导性的，因为瓶颈的任务可能会比5％的速度慢得多。
几乎有同样多的CPU进程在等待工作？ （=>坏）
大概记得CPU的大部分运行任务和任务是什么请求IO。 如果两个独立的任务忙于在两个单独的CPU上查询同一个磁盘，则这将使两个CPU都处于100％IOWait（并且在20个CPU示例中，IOWait的整体平均值为10％）。
基本上，如果你有很多任务要求IO，特别是从同一个磁盘上，加上该磁盘被100％利用（见iostat -mtx ），那么这是不好的。
工作进程正在等待执行计划的5.0％ （在这种情况下=> OK）
不。工作stream程几乎肯定是等待IO的全职工作。 这只是平均报告情况（“其他CPU不忙”）欺骗的百分比或事实，即CPU有许多任务运行，其中许多不需要做IO。
一般来说，在多CPU系统中，IOWait百分比等于您除以100的CPU数量，这可能是需要调查的。
别的东西
往上看。 但请注意，执行非常繁重的应用程序会受到限制（停止使用写回，直接开始写入磁盘）。 这导致这些任务产生高IOWait，而在同一个CPU写入同一个磁盘的其他任务不会。 所以exception确实存在。
另外请注意，如果您有1个专用于运行2个任务的CPU，一个是繁重的IO读取/写入器，另一个是CPU用户繁重，则在这种情况下，CPU将报告50％的IOWait，如果您有10个任务将是10％IOWait（和一个可怕的负载），所以这个数字可以被报告比实际上是一个问题要低得多。
我认为你真的需要看看iostat -mtx来获得一些磁盘利用率指标，并且用pidstat -d来获得一些每进程指标，然后考虑那些以这种方式触及这些磁盘的应用程序是否可能导致问题或其他潜在的应用程序可能会导致问题。
CPU指标确实是潜在问题的指标，它们是一般的，所以理解它们可能过于宽泛的地方是一件好事。
等待状态是当其他可运行的进程停止等待IO时。 这是一个争议的迹象，通常是磁盘资源。
这确实意味着你的一些进程没有尽可能快地运行，但这是非常正常的。
这意味着5％的CPU时间用于等待磁盘IO完成，6.7％的CPU时间用于实际进行用户级进程所需的处理。
检查vmstat输出; 例如vmstat 1 30 ，只要列b中的进程数不会堆积起来，那就好了。 列b表示在磁盘IO操作完成之前被阻塞的处于不可中断状态（D状态）的进程的数目。
所以回答你的问题
没有时间大致相同，但这不一定是个问题。 只要你没有问题的地方在D状态下开始打桩，你是好的。 改进之处可能包括增加更多的内存以获得更多的页面caching空间（diskcache）来减less磁盘读取次数，而是从内存caching中读取调优磁盘调度程序。
这是用于处理用户级进程的CPU时间的一部分; 这里没有什么值得担心的，特别是空闲的85.5%id CPU时间