比较 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