2020年4月10日晚上7点09分左右，运维群反馈大盘视图跌落，并且有机器异常重启。
随即，查看异常重启的机器监控数据，发现包量涨了，从而导致内存占用涨了
按照排查套路，登录机器查看dmesg和/var/log/message，看不出问题来。
那就看下有没有vmcore产生。进入/var/crash发下确实有core文件生成
先看下vmcore-dmesg.txt信息
从vmcore-dmesg.txt看到由于oom，业务进程被kill掉了（OOM计算规则主要是根据进程的占用的物理内存+swap+页表大小得到一个oom_score，然后选取最大的进行kill，详细过程可阅读kernel源码mm/oom_kill.c，这里就不赘述了）。
其次就是内核线程khugepaged D住了。
把vmcore放到自己的开发机上debug一下。
发现debug不了，看上去是vmcore文件有问题。那只能从vmcore-demsg.txt文件结合监控进行分析。
从vmcore-dmesg.txt看到内核线程Khugepaged D住了，这个线程是干什么的？为什么会D住呢？机器重启和这个有没有关系呢？
Khugepaged是个内核线程，主要是处理大页内存管理问题。（自己google下吧，这里也不赘述了）
那Khugepaged为什么会D住呢？根据call trace查看对应的内核源码。
卡在获取rw_sem。
另外看下系统的panic设置
系统的panic是打开的，并且D状态超过120秒之后，就会触发系统panic。由于kernel.panic=5，因此当系统挂起后5秒，就会触发系统reboot，所以机器重启了。
整体的流程图如下：
那有没有办法不让系统在panic的时候出现重启呢？可以，修改内核参数即可。但还是没有解决khugepaged被D住的问题。根因还是内核线程D住了，因此先看下社区有没有类似的问题。从社区上看有人反馈过相同的问题。
https://lore.kernel.org/patchwork/patch/863232/
并且有对应的patch，将down_read改为down_read_trylock，避免长时间获取不到锁出现hung住的问题。
这里也查看了linux 4.9.104内核版本，确实已经修复了。
https://elixir.bootlin.com/linux/v4.9.104/source/mm/khugepaged.c
