Linux 宕机-Kernel Crash的原因分析-第一批

日常工作中，经常遇到各类服务器"hang"死，load暴涨，无法ssh只能无奈重启的情况，“hang” 死只是表象，其实大多数原因都可以避免，简单总结下:

场景1：

task blocked

Jan  1 09:30:03 mydev kernel: INFO: task java:18777 blocked for more than 120 seconds.
Jan  1 09:30:03 mydev kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

有时候服务器卡死无法登录，好在syslog及时收到了kernel log，发现是java 进程导致了IO Block，日志说可以通过echo 0 > /proc/sys/kernel/hung_task_timeout_secs 去避免这个告警, 先不看如何解决，先看以下原因。

root cause:

一般情况下Linux写磁盘时会用到缓存，这个缓存大概是内存的40%，只有当这个缓存差不多用光时，系统才会将缓存中的内容同步写到磁盘中。但是操作系统对这个同步过程有一个时间限制，就是120秒。如果系统IO比较慢，在120秒内搞不定，那就会出现这个异常。这通常发生在内存很大的系统上。

solution:

• /sbin/sysctl -w vm.dirty_ratio=10

根据上面的root cause，直接把系统缓存降低到10%，让一次性刷新的内存量变小，刷新频率变大，默认是20-40。

• echo noop > /sys/block/sda/queue/scheduler

修改磁盘的IO调度策略，修改为最基本的noop策略，其他策略可以自己去查。

• /sbin/sysctl -w kernel.hung_task_timeout_secs = 0

还要就是内核日志提示的修复方法，比较粗暴，就是不设置超时时间，IO慢就慢，慢慢阻塞就好了，只能说治标不治本。
当然以上方法只是一定程度上的避免，但如果还不行，只能说IO真的跟不上业务了，只能扩容了。

场景2：

soft lockup

Jan  1 09:30:03 mydev kernel: BUG: soft lockup - CPU#0 stuck for 23s! [init:1]

有时候代码调用kernel 锁会遇到，以前有些大佬写Linux 内核模块的时候也经常遇到，先分析以下这个日志背后的原理

root cause:

linux有个watchdog进程, 就是知名的"看门狗"进程, watchdog是个用户态/内核态都有进程的服务，他会监控CPU使用时间的信息并同步到kernel，然后内核有个interrupt函数会调用softlockup计数器，把当前时间和收集到的时间进行比较，如果超过一个阈值，则认为watchdog没有收集到CPU使用时间的信息，可以理解为watchdog 对CPU的心跳失败，kernel就会报出soft lockup的报错。

solution:

• echo 30 > /proc/sys/kernel/watchdog_thresh

修改超时时间，最大可以设置到60，超时时间是2*watchdog_thresh ，比如设置到60就是120S后超时, 同样也是治标不治本的办法，最好还是开启panic，echo “1” > /proc/sys/kernel/panic, 具体可以从CPU 超配, CPU太慢或者IO太高，代码报错的stack进行排查。

场景3:

oom

Aug  1 02:22:36 G*******LNX01 kernel: hald invoked oom-killer: gfp_mask=0x200da, order=0, oom_adj=0
Aug  1 02:22:37 G*******LNX01 kernel: hald cpuset=/ mems_allowed=0

root cause:

这个不在赘述了，就是内存超了。

solution:

• vm.overcommit_memory = 1

不推荐，表示内核允许分配所有的物理内存，而不管当前的内存状态如何，就是服务器有多少物理内存就给你多少，适当的扩大了能分配的内存数量，治标不治本。

• echo -15 > /proc/$pid/oom_score_adj

修改oom_adj的优先级, 该优先级是-1000 到1000, 数值越小，越不容易被Kill，这个可以保护重要的应用。

个人公众号, 分享一些日常开发，运维工作中的日常以及一些学习感悟，欢迎大家互相学习，交流