Centos kdump使用中的问题

centos机器配置了kdump后，在意外宕机后，会生成vmcore以便机器重启后分析问题原因。但是在高性能机器中，由于内存配置非常大，使得每次panic后重启时间比较长(内存256G，系统盘为双ssd组成的raid1，时间大概20分钟左右)。在线上业务不能长时间处于中断状况下，往往都会通过带外强行重启，使得vmcore文件不能完整的生成，这样给后续分析与解决问题造成很大困难。

本文的目的是优化kdump，减少系统宕机时生成vmcore的时间，或者通过其他方式获取内存中指定的信息。

 

解决方案

从centos6.4 开始，在系统panic时会多生成一个vmcore-dmesg.txt文件，此文件记录的就是panic时刻栈信息，接着生成vmcore文件。
这样即使vmcore生成过程中，强行重启机器，依然有栈信息可以分析。

 

遇见问题

1. vmcore生成过程中强行重启机器，vmcore-dmesg.txt文件未生成，定位原因为内存数据还未下刷到磁盘。在centos6.6中已经修补此问题，解决办法就是在vmcore-dmesg.txt文件生成后，调用了sync命令
2. 在打了热补丁的机器上，由于lsmod查看到部分模块已经从/lib/modules下删除，导致生成kdump.img过程中找不到对应的ko文件而失败，这个可以更改/sbin/mkdumprd脚本，增加modinfo判断模块是否存在，如果不存在，则该模块就skip
3. 将centos7内核移植到centos6中，由于centos7内核ext4兼容ext3，默认ext3模块不编译，使用centos6系统自带/sbin/mkdumprd脚本生成kdump.img会触发找不到ext3模块的错误，解决办法可以有以下几种：
     3.1 使用centos7中的/sbin/mkdumprd、kdump-lib.sh脚本，并修改/sbin/mkdumprd脚本中dracut命令，去掉--hostonly-cmdline参数(测试失败，参数--hostonly-cmdline很重要)
     3.2 使用centos6自带的/sbin/mkdumprd脚本，判断模块名称为ext3时，强行换成ext4  (测试成功，但方法不好)
4. yum update kexec-tools执行完后，重启kdump服务卡住，原因为/var/lock/kdump文件存在，导致锁等待，进一步定位，为第一次mkdumprd命令执行未退出