记一次设备不断重启的排查经历
实际上事情已经过去好几天了,最近稍微松懈一些,决定对之前遇到的一个奇怪问题以及排查过程记录一下。
问题现象
- 设备起来,用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问题描述具体如下:
对比上面的的条件以及问题设备发现恰好一致。
- CPU型号符合
- 内核版本经过比对也是符合
- 设备在问题之前已经运行了217天
- 设备 /var/log/messages 日志中有 hung_task: blocked tasks 日志
- 设备有较多进程处于D状态
- 设备top CPU利用率已经时间很大,这里要认真观察才能看出来
红帽对于该问题介绍红帽问题433833
问题结论&解决方案
该问题系内核和cpu结合产生的一个TSC时间错误问题。可以升级内核或者补丁方式处理。
排查总结
- 基本工具要善于使用:vmstat iotop iostat free top ps 等
- 对系统了解,本案中进程stack调用栈产看至关重要
- 系统黑匣子,messages日志,业务日志查看也许都能捕捉蛛丝马迹
- 资料查询并核实
鸣谢&参考资料
感谢公司大佬关键时刻的指点,感谢前人的努力,很好奇这种bug怎么查出来的,这个功夫深啊。
[1]:stub_execve问题描述
[2]:红帽问题433833
[3]:TSC时间错误问题及解决方案