排查路径：
1、一开始怀疑可能是io阻塞导致，于是使用iostat -xdm 1 100，查看 io状况，发现io不高
2、于是使用top，查看系统负载情况。发现系统负载很高，但是cpu使用率比较低，同时wa也不多，难道是正在执行的进程数很多。
3、另起一个窗口 执行 vmstat 1 10 查看系统状态，没有发现异常，于是怀疑是不是进程D状态导致。
4、于是free -g 查看内存使用情况，发现free的内存为0，但是buff/cache还有13G
5、使用ps -ef 查看有哪些进程，结果 ps -ef 显示到一半就直接hung死了。
6、于是执行ps aux，没有执行完成时，也hung死了，这时发现有很多D状态的进程，这就很恐怖了，为什么这么多D状态的进程。
7、于是查看/var/log/message，发现大量的call_trace, 依次是kthread kspwad java java java, 后面都是大量的java oom
看调用链，系统内存不足了，在回写数据。
从内存不足、磁盘IO多这两个方面考虑
根据下图红框中的函数：在申请内存，回收cache 中的object，刷cache object的过程当中，就bug了。。
从top的截图来看：可用内存只有251M了
根据free –g,如下图：表明系统空闲内存少于1个G，
根据下图：RES是进程使用的实际物理内存，图中显示：0.023t * 1024 = 23.552G java大概占用了23G的内存，在加上buff/cache。基本没有多余的内存了。
总结：由于内存不足，导致java进程的mmap操作的物理内存需求无法得到满足，连带负责内核内存管理、数据回写的内核线程进程D状态，进而导致load飙升。
l Java占用内存：23552M(23G)，在获取内存时，由于无法立刻得到满足，进入D状态；
l 日志里的oops里的函数表明，系统在偿试申请存页、回收cache object，并且由于某些条件不满足，导致D状态；
l Top的load值是负载最高的cpu核心上的队列大小为基准计算的，包括了D状态的进程（TASK_UNINTERRUPTIBLE）
