离线业务反馈有台VM机器ssh登录不了，从监控看所有指标都掉0了，机器并没有重启，因此怀疑系统可能hung住了，但由于系统没有重启，因此可以判断系统上的进程应该没有一直处于D状态，在系统开启了hung task panic的条件下，即hung_task_panic=1，如果处于D状态超过hung_task_timeout_secs
由于从监控（包括monitor，宿主机log等）也看不出异常，并且母机上也无法通过virsh console到子机，因此唯一的办法就是dump虚机的内存快照通过分析内存快照看有什么异常。
dump虚拟机的内存快照信息，dump出来的内存信息可以通过crash进行debug，类似于vmcore调试。dump内存命令如下所示：
virsh dump –memory-only ins-uc4dv1w2oqa.img
由于业务VM使用的内核是4.19版本，因此需要先安装对应版本的debugginfo包，从网站上nt上下载对应的包并在母机上安装之后，就可以使用crash命令进行debug调试。
调试命令为：crash /boot/vmlinux-4.19.95-17/data0/a.img
从堆栈可以看到有很多进程在执行内核内存回收的操作，看下系统内存使用情况
内存使用率已经达到99%以上，并结合宿主机上子机所占CPU的监控信息可以看到系统负载非常高，所有的核心使用率都在99%（母机上的监控忘记截图了）
另外，从内存快照分析看到有一部分进程处于D状态，但由于系统没有panic，所以推断只是临时处于D状态，为什么处于D状态，主要是大量进程从缺页异常入口，调用内存回收接口：shrink_inactive_list -> msleep，使得该进程状态变为 D ，D状态进程堆栈信息：
根据内核源码分析
说明是大量的进程疯狂地调用 shrink_inactive_list 又被阻塞了一下子，又退出去，又掉进来。所以，不是一直卡死，而是性能瓶颈拥堵在这个地方。
因此根因是内存回收瓶颈，内存回收不及时，内存需求量巨大，而 LMK 没触发，内存有很多匿名页，都在回收和回写文件页等
