按照linux系统的设计哲学,内核只提供dump内存的机制,用户想要dump什么样的内存,dump多少内存是属于策略问题,由用户来决定。
在真实的使用场景中,主要有两种使用方式:
一种是dump某一个进程的地址空间来供用户在进程挂掉之后debug分析,也就是通常所说的coredump,这个在下一篇中描述;
另一种就是dump整个系统的内存空间,以便于系统管理员debug分析系统挂掉的原因,也就是本文描述的kdump。
由于dump内存的逻辑依然需要系统可以正常工作,管理系统的各种资源,所以kdump整个过程依赖kexec和一个额外的dump内核来保证整个流程正确的执行。
下图描述了kdump的整个流程:
- kdump专用内核,通过kexec工具load到预留的内存中,供故障引导使用
- kexec工具,负责加载crash内核,以及一些启动参数传递
- makedumpfile工具,负责将故障内核的内存copy,压缩,写去指定文件
kdump整个流程涉及到两次内核启动:
- 首先是工作内核启动,包括硬件自检初始化,bootloader加载内核并发引导内核启动,然后配置预留内存,并使用kexec工具将crash内核加载到保留内存中。
- 工作内核在遇到故障触发panic之后启动crash kernel,kexec启动crash kernel只执行内核初始化逻辑,不再做硬件自检初始化,启动速度很快。
- crash内核加载好之后可以正常管理一部分系统资源,通过/proc/vmcore内存镜像文件,将故障内存经过压缩之后写入到硬盘的dump文件中保存
- 捕获完毕之后重启系统,完成故障恢复
随着系统内存的不断增大,故障恢复时间也随之线性增加,两次系统启动时间比较固定,线性增加的时间主要是受copy内存、压缩内存以及文件落盘影响。所以社区也出现了很多kdump优化的方案,主要也是针对这个几个方面实现的:
- copy内存方面,为了减少系统调用的次数,实现了vmcore的mmap方法,可以提高copy的效率
- 内存压缩方面,引入了压缩效率比较高的lzo算法来替换原来的gzip算法
- 落盘方面主要考虑并发写文件和优化io效率
- 修改启动参数,增加crashkernel字段,通过/proc/cmdline可以观察是否生效
- 安装kdump组件包,包括crash kernel和kexec组件
- 启动kdump服务,通过service命令或者/etc目录中的启动脚本启动
- 观察/proc/iomem中是否成功load了crash kernel
本文来自网易实践者社区,经作者赵建明授权发布。