开头还是介绍一下群，如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到2群（共950人左右 1 + 2 + 3）新人会进入3群
我见过很多Linux性能工程师将CPU使用率中的“IOWait”部分视为指示系统是否受到I/O限制的东西。在本博客文章中，我将解释为什么这种方法是不可靠的，并介绍你可以使用的更好的指标。
让我们先进行一个小实验——在系统上产生大量的I/O使用：
sysbench --threads=8 --time=0 --max-requests=0 fileio --file-num=1 --file-total-size=10G --file-io-mode=sync --file-extra-flags=direct --file-test-mode=rndrd run
截止目前为止，一切都OK，可以看到I/O密集型工作负载明显对应于高的IOWait值（在vmstat中的“wa”列）。让我们继续运行我们的I/O限制工作负载并加入一个占用CPU大量负载：
sysbench --threads=8 --time=0 cpu run
发生了什么？IOWait完全消失了，现在这个系统看起来完全没有受到I/O限制！
实际上，我们的第一个工作负载没有改变——它仍然受到I/O限制；只是当我们查看“IOWait”时，它变得看不见了！
要理解发生了什么，我们真的需要理解“IOWait”是什么以及它是如何计算的。
有一篇很好的文章对这个主题进行了更详细的介绍，但基本上，“IOWait”是闲置的CPU时间。如果CPU核因为没有要执行的工作而空闲，那么这段时间就被归到“idle”中。然而，如果CPU核因为某个进程正在等待磁盘而处于空闲状态，则I/O时间被归类到“IOWait”中。
然而，如果一个进程正在等待磁盘I/O，但是系统中的其他进程可以使用CPU，那么这段时间将会被计入这些进程的用户/系统时间，而不是“IOWait”。
由于这种记账方式，其他有趣的行为也是可能的。现在，让我们不再运行8个I/O限制的线程，而是在4核虚拟机上运行一个I/O限制的进程：
sysbench --threads=1 --time=0 --max-requests=0 fileio --file-num=1 --file-total-size=10G --file-io-mode=sync --file-extra-flags=direct --file-test-mode=rndrd run
即使这个进程完全受到I/O限制，我们也可以看到IOWait（wa）并不是特别高，不到25%。在有32、64或更多核的大型系统上，这样完全受到I/O限制的进程几乎不可见，产生一位数字的IOWait百分比。
因此，高IOWait显示系统中许多进程在等待磁盘I/O，但即使IOWait很低，磁盘I/O在系统上的某些进程中可能仍会有瓶颈。
如果IOWait不可靠，那么什么指标可以取而代之，可以为您提供更好的可见性？
首先，查看应用程序特定的可观察性。如果应用程序已经进行了良好的仪表化，它往往最好知道何时会受到磁盘的限制，以及哪些特定任务受到了I/O限制。
如果您只能访问Linux指标，请查看vmstat中的“b”列，这对应于被阻塞在磁盘I/O上的进程。即使是CPU密集负载并发进行，这将显示这些进程，而遮盖了IOWait:
最后，您可以查看每个进程的统计信息，以查看哪些进程正在等待磁盘I/O
原文 https://www.percona.com/blog/understanding-linux-iowait/
