检查topio 等待后，我得到了以下数据：
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），它们是否意味着：
- 等待的 CPU 进程数几乎和正在运行的一样多？（=> 不好）
- 工作进程正在等待其执行计划的 5.0%？（=> 在这种情况下可以）
- 其他东西
答案1
评估这些数字时你需要小心谨慎。
- IOWait 与磁盘活动相关，但不一定呈线性相关。
- 您的 CPU 数量会影响您的百分比。
- 高 IOWait（取决于您的应用程序）不会一定表示存在问题。或者，小的 IOWait 可能表示存在问题。这基本上归结为正在等待的任务。
在此上下文中，IOWait 是指在给定时间段内 CPU（或所有 CPU）处于空闲状态的时间量度，因为所有可运行任务都在等待 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%？（=> 在这种情况下可以）
不。工作进程几乎肯定一直在等待 IO。这只是平均报告情况（“其他 CPU 不忙”）捏造了百分比或 CPU 有许多任务要运行的事实，其中许多任务不需要执行 IO。
一般来说，在多 CPU 系统上，IOWait 百分比等于 CPU 数量除以 100，这可能是需要调查的。
其他东西
参见上文。但请注意，执行大量写入操作的应用程序会受到限制（停止使用写回，开始直接写入磁盘）。这会导致这些任务产生高 IOWait，而同一 CPU 上写入同一磁盘的其他任务则不会产生高 IOWait。因此确实存在例外情况。
还要注意的是，如果你有 1 个 CPU 专用于运行 2 个任务，一个是重度 IO 读/写，另一个是重度 CPU 用户，那么在这种情况下 CPU 将报告 50％ IOWait，如果你有 10 个这样的任务，它将是 10％ IOWait（和可怕的负载），所以报告的数字可能比实际问题的数字低得多。
我认为您确实需要查看iostat -mtx一些磁盘利用率指标，并pidstat -d获取一些每个进程的指标，然后考虑以这种方式访问这些磁盘的应用程序是否可能导致问题，或者访问这些磁盘的其他潜在应用程序是否可能导致问题。
CPU 指标实际上可以作为潜在问题的指标，因此了解它们可能存在的位置也总体来说是一件好事。
答案2
等待状态是指原本可运行的进程因等待 IO 而停止。这是争用（通常是磁盘资源争用）的标志。
这确实意味着您的某些进程没有以应有的速度运行，但这很正常。
答案3
这意味着 5% 的 CPU 时间用于等待磁盘 IO 完成，6.7% 的 CPU 时间用于实际执行用户空间进程所需的处理。
检查 vmstat 输出；例如，vmstat 1 30只要列中的进程数b不堆积，就没问题。列b表示处于不可中断状态（D 状态）的进程数，这些进程在磁盘 IO 操作完成之前一直处于阻塞状态。
所以回答你的问题
- 等待的 CPU 进程数几乎和正在运行的一样多？（=> 不好）
没有时间大致相同，但这不一定是个问题。只要您没有遇到进程开始在 D 状态下堆积的问题，那就没问题。改进可能包括添加更多 RAM 以留出更多空间用于页面缓存（磁盘缓存），以减少磁盘读取次数，而是从内存缓存中读取，调整磁盘调度程序。
- 工作进程正在等待其执行计划的 5.0%？（=> 在这种情况下可以）
这是处理用户空间进程所花费的 CPU 时间的一部分；这里没有什么可担心的，特别是在有这么多空闲85.5%idCPU 时间的情况下