MongoDB系统CentOS 7.1 crash的排障过程

Posted 2021-01-30 携程DBA

【作者】

王栋：携程技术保障中心数据库专家，对数据库疑难问题的排查和数据库自动化智能化运维工具的开发有强烈的兴趣。

【问题描述】

最近我们有多台MongoDB的服务器CentOS 7.1系统发生了crash，会不定期的自动重启。

【排查思路】

1、碰到linux系统crash的问题，我们首先想到的是排查系统日志/var/log/message，看是否有硬件问题或其他原因。抽查了多台服务器在crash的时间点message中都没有记录异常信息。

2、对于CentOS 7的系统，我们可以使用journalctl工具查看内核以及服务等产生的日志信息，检查相关日志只记录发生过reboot，没有其他异常信息。

3、 一般linux系统都默认配置了kdump，kdump是基于kexec的内核崩溃转储机制，可以转储内核崩溃时的内存镜像。在其中一台服务器上我们在/var/crash/127.0.0.1-2018.12.26-00:31:04目录下找到了转储文件vmcore。

【排障过程】

1、 为了避免对生产环境造成影响，我们将vmcore文件拷贝到内核版本相同的一台测试服务器上

2、 使用crash工具分析vmcore文件，在测试服务器上先安装crash工具：

yum install crash

3、 安装debuginfo包，可以在官网上下载对应kernel版本的debuginfo包：

https://buildlogs.centos.org/c7.1511.u/kernel/20161024152721/3.10.0-327.36.3.el7.x86_64/

安装依赖包及debuginfo包：

rpm -ivh kernel-debuginfo-common-x86_64-3.10.0-327.36.3.el7.x86_64.rpm

rpm -ivh kernel-debuginfo-3.10.0-327.36.3.el7.x86_64.rpm

4、使用crash工具分析/var/crash下的转储文件vmcore，命令如下：

crash /usr/lib/debug/lib/modules/3.10.0-327.36.3.el7.x86_64/vmlinux vmcore

5、可以看到kernel crash时的Call Trace，关键信息见黄色背景字体：

crash> bt

PID: 9979 TASK: ffff8804b4020b80 CPU: 2 COMMAND: "crond"

#0 [ffff8804b42db778] machine_kexec at ffffffff81051e9b

#1 [ffff8804b42db7d8] crash_kexec at ffffffff810f27e2

#2 [ffff8804b42db8a8] oops_end at ffffffff8163f448

#3 [ffff8804b42db8d0] no_context at ffffffff8162f561

#4 [ffff8804b42db920] __bad_area_nosemaphore at ffffffff8162f5f7

#5 [ffff8804b42db968] bad_area at ffffffff8162f91b

#6 [ffff8804b42db990] __do_page_fault at ffffffff81642235

#7 [ffff8804b42db9f0] trace_do_page_fault at ffffffff81642403

#8 [ffff8804b42dba28] do_async_page_fault at ffffffff81641ae9

#9 [ffff8804b42dba40] async_page_fault at ffffffff8163e678

[exception RIP: netlink_compare+11]

RIP: ffffffff815560bb RSP: ffff8804b42dbaf8 RFLAGS: 00010246

RAX: 0000000000000000 RBX: 000000049f250000 RCX: 00000000c3637c42

RDX: 00000000000026fb RSI: ffff8804b42dbb48 RDI: 000000049f24fb78

RBP: ffff8804b42dbb30 R8: ffff8804b42dbb44 R9: 0000000000002170

R10: 0000000000000000 R11: ffff8804b42db966 R12: ffff88061dcd2678

R13: ffff8804b42dbb48 R14: ffffffff815560b0 R15: ffff88061b639000

ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018

#10 [ffff8804b42dbb00] rhashtable_lookup_compare at ffffffff813080d0

#11 [ffff8804b42dbb38] netlink_lookup at ffffffff815569ee

#12 [ffff8804b42dbb68] netlink_getsockbyportid at ffffffff81557d8f

#13 [ffff8804b42dbb80] netlink_alloc_skb at ffffffff81557dff

#14 [ffff8804b42dbbb8] netlink_ack at ffffffff8155a8a9

#15 [ffff8804b42dbbf0] audit_receive at ffffffff811067e7

#16 [ffff8804b42dbc18] netlink_unicast at ffffffff8155a02d

#17 [ffff8804b42dbc60] netlink_sendmsg at ffffffff8155a420

#18 [ffff8804b42dbcf8] sock_sendmsg at ffffffff815112d0

#19 [ffff8804b42dbe58] SYSC_sendto at ffffffff81511841

#20 [ffff8804b42dbf70] sys_sendto at ffffffff815122ce

#21 [ffff8804b42dbf80] system_call_fastpath at ffffffff81646b49

RIP: 00007f4ac19d5353 RSP: 00007ffe233b1fb8 RFLAGS: 00010202

RAX: 000000000000002c RBX: ffffffff81646b49 RCX: 0000000000000000

RDX: 000000000000009c RSI: 00007ffe233b1ff0 RDI: 0000000000000003

RBP: 00007ffe233b1ff0 R8: 00007ffe233b1fe0 R9: 000000000000000c

R10: 0000000000000000 R11: 0000000000000246 R12: ffffffff815122ce

R13: ffff8804b42dbf78 R14: 000000000000044d R15: 0000000000000001

ORIG_RAX: 000000000000002c CS: 0033 SS: 002b

6、搜索rhashtable_lookup_compare关键字，定位到这是kernel Linux 3.10.0-327.36.3.el7.x86_64的一个bug，详细描述可以参见下面，该bug在 7.3 kernel (3.10.0-514.el7)后修复：

https://bugs.centos.org/view.php?id=12012

【定位bug触发条件】

1、考虑到升级系统成本较高，尝试定位触发bug的条件，可以看到触发这个bug是crond命令：

PID: 9979 TASK: ffff8804b4020b80 CPU: 2 COMMAND: "crond"

2、借助systemtap工具，在发生crash的kernel函数上加探针，并打印kernel backtrace，process id，process name等信息，脚本如下：

probe kernel.function("rhashtable_lookup_compare") {

print_backtrace();

printf ("%d
%s
", pid(),execname());

} 

3、抓取到crond等系统命令确实会调用rhashtable_lookup_compare函数，而其他命令的调用堆栈并不完全相同：

25756

crond

0xffffffff81308080 : rhashtable_lookup_compare+0x0/0x90 [kernel]

0xffffffff815569ee : netlink_lookup+0x4e/0x80 [kernel]

0xffffffff81557d8f : netlink_getsockbyportid+0x1f/0x70 [kernel]

0xffffffff81559fe9 : netlink_unicast+0xa9/0x1b0 [kernel]

0xffffffff8155a8f9 : netlink_ack+0x99/0x110 [kernel]

0xffffffff811067e7 : audit_receive+0x67/0xa0 [kernel]

0xffffffff8155a02d : netlink_unicast+0xed/0x1b0 [kernel]

0xffffffff8155a420 : netlink_sendmsg+0x330/0x770 [kernel]

0xffffffff815112d0 : sock_sendmsg+0xb0/0xf0 [kernel]

0xffffffff81511841 : SYSC_sendto+0x121/0x1c0 [kernel]

0xffffffff815122ce : SyS_sendto+0xe/0x10 [kernel]

0xffffffff81646b49 : system_call_fastpath+0x16/0x1b [kernel]

4、考虑到MongoDB最近新上了一套监控的脚本是通过crontab调度的，而上监控之前服务器重启的情况很少。猜测可能是crontab调度系统监控程序触发了kernel bug，后面将监控脚本改为服务的方式观察是否可以规避触发bug。

【解决思路】

我们通过分析kernel crash时的转储文件，定位到CentOS 7.1系统存在自动重启的bug，建议新的linux服务器都采用CentOS 7.4的系统。
考虑到升级系统成本较高，将crontab调度的程序改为服务的方式，来尝试规避触发bug。