比较 kdump makedumpfile 中的压缩方法

背景

在出现 Kernel Panic 的时候,kdump 可以帮助我们收集 vmcore, 以便后续对故障原因进行分析。然而,近些年的服务器动辄上百G的内存,转储一个 vmcore 所耗费的时间显得相对较长,增加了 down time.

在 RHEL7/CentOS7 中, kdump 提供了三种压缩方法(zlib, lzo, snappy),我们可以选择一种较快速的压缩方法来节省收集 vmcore 的时间。

压缩方法可以在 kdump.conf 中的 makedumpfile 一行里设置。

# man makedumpfile

-c,-l,-p
  Compress dump data by each page using zlib for -c option, lzo for -l option or snappy for -p option.  (-l option needs USELZO=on and -p option needs USESNAPPY=on when building)
  A user cannot specify this option with -E option, because the ELF format does not support compressed data.
  Example:
  # makedumpfile -c -d 31 -x vmlinux /proc/vmcore dumpfile

zlib 是 gzip 所使用的压缩方法,通常而言它比 lzo 和 snappy 慢,而压缩比稍微高于 lzo 和 snappy.

测试方法

要比较这几种压缩方法对收集 vmcore 时间的影响,还是应该结合实际情况进行测试,毕竟应用、硬件、网络不尽相同。

测试的方法很简单。故意配置错误 kdump.conf 的一些选项,在 Kernel Panic 之后,就会进入到 kdump 的 shell 里面,我们可以在这个 shell 里手动收集 vmcore,并测量时间。

1. 修改 /etc/kdump.conf,将 default 设置为 shell, 在 core_collector 的 makedumpfile 参数中随便添加一串假选项。

 path core
 ext4 /dev/sdb
 core_collector makedumpfile -l --message-level 1 -d 31 --xxxxxx  ### Fake one.
 default shell
 

2. 重新启动 kdump 服务。

# systemctl restart kdump

3. 在系统中模拟实际应用的运行,然后手动触发 Kernel Panic.

# echo c > /proc/sysrq-trigger

4. 随后,由于 kdump 收集失败,会自动进入一个 shell.

5. 在 shell 中,尝试通过不同压缩方法手动收集 vmcore,并比较收集时间。在我的虚拟机里,测试的时间如下。

## Case 1, no compression.
# time makedumpfile --message-level 1 -d 17 /proc/vmcore /kdumproot/mnt/kdump/core/vmcore_no_compress
real 1m39.197s
user 0.442s
sys 0.325s

## Case 2, -c, zlib
# time makedumpfile -c --message-level 1 -d 17 /proc/vmcore /kdumproot/mnt/kdump/core/vmcore_zlib
real 37.890s  <<<------ Total time consumed, including IO time.
user 7.089s   <<<------ Approx time for compression
sys 2.021s

## Case 3, -l, lzo
# time makedumpfile -l --message-level 1 -d 17 /proc/vmcore /kdumproot/mnt/kdump/core/vmcore_lzo
real 46.176s
user 1.087s
sys 0.178s

## Case 4, -p, snappy
# time makedumpfile -p --message-level 1 -d 17 /proc/vmcore /kdumproot/mnt/kdump/core/vmcore_snappy
real 49.060s
user 1.010s
sys 0.148s

6. 从压缩后的文件大小来看,压缩比相差不大。

  -rw-------. 1 root root 126M Oct 11 09:24 vmcore_lzo
  -rw-------. 1 root root 277M Oct 11 09:19 vmcore_no_compress
  -rw-------. 1 root root 131M Oct 11 09:26 vmcore_snappy
  -rw-------. 1 root root 104M Oct 11 09:21 vmcore_zlib

7. 由此来看,在我的虚拟机中, zlib 实际上速度最快。需要留意的是,在 kdump 环境里也会有 buffer/cache 的影响,做完每个测试后要执行 sync。以及可以调换 zlib, lzo, snappy 的测试顺序,尽可能排除无关因素的影响。

8. 从客户提供的测试结果看,在他的环境中, lzo 和 snappy 的速度都大大优于 zlib.

## Case 1, no compression.
# time makedumpfile --message-level 1 -d 17 /proc/vmcore /kdumproot/var/crash/vmcore_no_compress
real 4m6.066s
user 0m15.944s
sys  0m31.376s

## Case 2, -c, zlib
# time makedumpfile -c --message-level 1 -d 17 /proc/vmcore /kdumproot/var/crash/vmcore_zlib
real 13m17.774s       <<<------ Total time consumed, including IO time.
user 12m51.372s     <<<------ Approx time for compression
sys  0m17.919s

## Case 3, -l, lzo
# time makedumpfile -l --message-level 1 -d 17 /proc/vmcore /kdumproot/var/crash/vmcore_lzo
real 2m14.918s       
user 0m49.984s    
sys  0m16.674s

## Case 4, -p, snappy
# time makedumpfile -p --message-level 1 -d 17 /proc/vmcore /kdumproot/var/crash/vmcore_snappy
real 2m18.559s     
user 0m33.716s
sys  0m16.892s

参考资料

Improvements on Kdump Scalability Issues for Terabyte-Scale Memory System