一般来讲，cpu使用率和iowait都会导致系统的loadavg很高，而且很多人也只限于cpu使用率和iowait导致系统的loadavg很高，于是，发现loadavg很高时，赶紧看看是cpu导致的还是iowait导致的，一般来讲都能很快定位问题；但是当发现cpu使用率几乎为0，iowait几乎为0，但是loadavg奇高便目瞪口呆了。
其实，不仅io等待会影响loadavg，其它资源的等待（如： 内存）也会导致loadavg的升高，只是很少遇到而已；一般来讲，进程在申请资源的时候，进程状态标识为D，如果很多进程状态为D，或者某些进程长时间处于状态D，都将导致loadavg的升高，而且进程的这种状态是非可中断的，试图发现阻塞在哪里的时候，发现的却是，strace的时候，strace没有响应，ltrace的时候，ltrace没有响应，pstack的时候，pstack没有响应，甚至ctrl+c都无法终止，幸运的话，ctrl+z可以推到后台并停止，然后kill 之
一般来讲，问题只要容易重现，就容易解决，不容易重现，就比较麻烦；尤其，等待内存资源的情况不太常见，如果真的没有内存了，你还能继续调试吗？而且默认情况下，当没有内存的时候，系统便会祭出oom来大开杀戒了；那么如何模拟呢？
docker给我们提供了限制内存使用（其实是cgroup）功能，而且可以设置禁用oom，那么，这就够了；在禁用oom的情况下，限制内存使用1g（注意最好禁用swap），然后启动容器，运行一个程序试图在容器里面申请2g的内存，我们将会发现进程申请1g内存之后卡住不动，系统cpu不高、iowait不高，loadavg在慢慢攀升
一个真实的情景：
在不晓得docker默认存储空间107G的情况下，把存储空间用满了，然后iowait很高，系统的loadavg也很高