记一次设备不断重启的排查经历

实际上事情已经过去好几天了，最近稍微松懈一些，决定对之前遇到的一个奇怪问题以及排查过程记录一下。

问题现象

• 设备起来，用uptime查看设备的负载不断增高，设备24核，启动后正常的负载18左右。
• 负载不断增高，达到160左右设备重启，周而复始。

排查过程

• 负载很高时候free -m查看设备的剩余内存，很充足，多达13G(设备一共内存32G)
• top 查看设备的整体负载，每个cpu都有很大的空闲，一段时间（15s左右）内没发现异常
• 在设备上执行诸如ls，ps aux 类似的命令有时候一会卡死，ctrl+c没有任何的响应
• ps aux | wc -l 查看系统一共进程才980+个，不算多
• ps aux | grep "D " 多达几十个进程处于D状态
• 既然处于D状态（不可描述中断），怀疑是在等待I/O，因此有如下的排查过程
  • smartctrl 查看磁盘是否坏道，未发现异常
  • iostat 查看磁盘的使用率，并无异常
  • iotop工具查看使用磁盘非常高的进程，并无异常
  • vmstat 查看I/O的等待情况，并无异常，但是结果的r这列持续在40+，和D状态的进程数基本一致，r表示等待CPU的进程数
• 随机选择几个D状态的进程，查看调用栈(cat /proc/$pid/stack)都是卡在如下地方
  

至此想必就是这里的问题了，看起来是内核的bug了，修炼不到家，似乎搞不定，于是使用百度(公司不能上google)搜索stub_execve看到一个小伙似乎遇到过这样的问题，参见stub_execve问题描述具体如下：

对比上面的的条件以及问题设备发现恰好一致。

1. CPU型号符合
2. 内核版本经过比对也是符合
3. 设备在问题之前已经运行了217天
4. 设备 /var/log/messages 日志中有 hung_task: blocked tasks 日志
5. 设备有较多进程处于D状态
6. 设备top CPU利用率已经时间很大，这里要认真观察才能看出来
   红帽对于该问题介绍红帽问题433833
   

问题结论&解决方案

该问题系内核和cpu结合产生的一个TSC时间错误问题。可以升级内核或者补丁方式处理。

排查总结

• 基本工具要善于使用：vmstat iotop iostat free top ps 等
• 对系统了解，本案中进程stack调用栈产看至关重要
• 系统黑匣子，messages日志，业务日志查看也许都能捕捉蛛丝马迹
• 资料查询并核实

鸣谢&参考资料

感谢公司大佬关键时刻的指点，感谢前人的努力，很好奇这种bug怎么查出来的，这个功夫深啊。
[1]:stub_execve问题描述
[2]:红帽问题433833
[3]:TSC时间错误问题及解决方案