MongoDB系統CentOS 7.1 crash的排障過程

##【做者】 王棟：攜程技術保障中心數據庫專家，對數據庫疑難問題的排查和數據庫自動化智能化運維工具的開發有強烈的興趣。

##【問題描述】 最近咱們有多臺MongoDB的服務器CentOS 7.1系統發生了crash，會不按期的自動重啓。

##【排查思路】 一、碰到linux系統crash的問題，咱們首先想到的是排查系統日誌/var/log/message，看是否有硬件問題或其餘緣由。抽查了多臺服務器在crash的時間點message中都沒有記錄異常信息。

二、對於CentOS 7的系統，咱們可使用journalctl工具查看內核以及服務等產生的日誌信息，檢查相關日誌只記錄發生過reboot，沒有其餘異常信息。

三、 通常linux系統都默認配置了kdump，kdump是基於kexec的內核崩潰轉儲機制，能夠轉儲內核崩潰時的內存鏡像。在其中一臺服務器上咱們在/var/crash/127.0.0.1-2018.12.26-00:31:04目錄下找到了轉儲文件vmcore。

##【排障過程】 一、 爲了不對生產環境形成影響，咱們將vmcore文件拷貝到內核版本相同的一臺測試服務器上

二、 使用crash工具分析vmcore文件，在測試服務器上先安裝crash工具：

<pre><code>yum install crash</code></pre>

三、 安裝debuginfo包，能夠在官網上下載對應kernel版本的debuginfo包：

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

安裝依賴包及debuginfo包：

<pre><code>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</code></pre>

四、使用crash工具分析/var/crash下的轉儲文件vmcore，命令以下：

<pre><code>crash /usr/lib/debug/lib/modules/3.10.0-327.36.3.el7.x86_64/vmlinux vmcore</code></pre>

五、能夠看到kernel crash時的Call Trace，關鍵信息見黃色背景字體：

<pre><code>crash> bt PID: 9979 TASK: ffff8804b4020b80 CPU: 2 COMMAND: <span style="background-color:#FFFF00">"crond"</span> \#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: <span style="background-color:#FFFF00">netlink_compare</span>+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] <span style="background-color:#FFFF00">rhashtable_lookup_compare</span> 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</code></pre>

六、搜索rhashtable_lookup_compare關鍵字，定位到這是kernel Linux 3.10.0-327.36.3.el7.x86_64的一個bug，詳細描述能夠參見下面，該bug在 7.3 kernel (3.10.0-514.el7)後修復：

<pre><code>https://bugs.centos.org/view.php?id=12012</code></pre>

##【定位bug觸發條件】

一、考慮到升級系統成本較高，嘗試定位觸發bug的條件，能夠看到觸發這個bug是crond命令：

<pre><code>PID: 9979 TASK: ffff8804b4020b80 CPU: 2 COMMAND: <span style="background-color:#FFFF00">"crond"</span></code></pre>

二、藉助systemtap工具，在發生crash的kernel函數上加探針，並打印kernel backtrace，process id，process name等信息，腳本以下：

<pre><code>probe kernel.function("rhashtable_lookup_compare") { print_backtrace(); printf ("%d\n%s\n", pid(),execname()); } </code></pre>

三、抓取到crond等系統命令確實會調用rhashtable_lookup_compare函數，而其餘命令的調用堆棧並不徹底相同：

<pre><code>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]</code></pre>

四、考慮到MongoDB最近新上了一套監控的腳本是經過crontab調度的，而上監控以前服務器重啓的狀況不多。猜想多是crontab調度系統監控程序觸發了kernel bug，後面將監控腳本改成服務的方式觀察是否能夠規避觸發bug。

##【解決思路】 咱們經過分析kernel crash時的轉儲文件，定位到CentOS 7.1系統存在自動重啓的bug，建議新的linux服務器都採用CentOS 7.4的系統。 考慮到升級系統成本較高，將crontab調度的程序改成服務的方式，來嘗試規避觸發bug。

原文出處：https://www.cnblogs.com/CtripDBA/p/10198811.html