coredump 瘦身風云
繼上一篇非典型程序員青囊搞定內存泄露問題后，美美地睡了一覺。睡夢中，突然金光閃閃，萬道光芒照進時光隧道，恍惚來到大唐神龍年間。青囊此時化身狄仁杰高級助理，陪同狄老大和元芳及千牛衛來到案發現場，一番勘察后迅速鎖定真兇。雖整日伏于桌前寫代碼，但早被生活馴服得謹小慎微、擅于察言觀色的青囊亦早已悟透了這斷案的奧秘。
只是，站在一旁的元芳眉頭緊鎖，面露難色......
狄公上前問道：元芳，有心事？
元芳起身答道：“大人斷案如神，只是像長安這種要案頻繁的地方，每次案發，都要出動上百千牛衛來大面積封鎖現場，走訪上萬群眾，耗費人力不說，還嚴重阻塞交通，影響了正常的生產秩序，導致其它業務部門受損，一直以來是怨聲載道啊。”
狄公笑了笑，手指向青囊，“囊啊，給你元芳哥show一下”。
青囊一陣馬屁之后，從袋中摸出一羅盤，得意道：“我這乾坤袋喚做sysAk，這羅盤叫minicoredump，以后如何封鎖現場，看它就清楚了”。元芳接過羅盤，順手擺弄了幾下，上面顯示要封鎖的現場縮小了不少，官道也暢通許多。元芳臉色憂轉喜，不禁問道：有此利器，鎖定現場無憂矣！只是它是怎么做到的，還請大人示教一下。
狄公哈哈大笑：“不急，且聽我慢慢道來”。
什么是coredump？
coredump 顧名思義，就是核心轉儲。我們的程序在運行過程中，如果發生了異常退出，光靠程序自身log往往是很難定位問題根因的。操作系統提供了一套coredump機制，在異常發生的時候，將進程現場的vma信息存儲到core文件中去。利用這個文件，就能夠恢復異常現場的信息，定位人員可以從中獲取到變量值、棧信息、內存數據，程序異常時的運行位置（甚至記錄代碼行號）等等，提高問題定位效率。就像斷案最關鍵的步驟就是去獲取第一手信息，還原案發現場，在此基礎上進行案件推演。
那么，coredump的流程是什么樣子的呢？
如下圖所示，當進程發生故障的時候，內核就會啟動coredump機制將故障現場的vma等信息轉儲成core文件。故障過后，利用gdb加載coredump文件來還原故障現場。通過獲取故障現場變量值、調用棧等信息，可以快速確定故障類型，鎖定故障代碼位置，找到根因。
就像狄公每次一次斷案，都要先鎖定發現場，然后親自勘查，提取所有物證和證言，結合現場信息推演，還原案發經過，最終鎖定作案元兇。
coredump資源消耗問題
操作系統在內核態生成core文件，是要將進程的有效vma信息全量dump出來。這就意味著大進程的coredump文件會非常龐大，甚至可以達到TB級別。這類大文件在生成和保存過程中嚴重消耗了IO、CPU、內存帶寬等資源，對系統的穩定性帶來沖擊。就像之前要偵破一起大案，需要封鎖方圓數公里內交通，動用數百警力做大量的摸排走訪工作。但隨著技術手段革新，收集信息也更準確，摸排手段也越來越精細化。同樣的，coredump信息收集是否也能做到精細化？
minicoredump登場
“元芳啊，定位問題，就像咱們天天去斷案一樣，走訪的關鍵是要先收集到高價值的線索，比如棧空間、data、bss等。其它的匿名頁信息，像堆空間，里面的數據雖然很重要，但是對于斷案來說大多情況下用不到，屬于低線索信息。而在大進程的vma信息中，低線索信息占比還非常高。因此，我們要有選擇、有目標地收集。這個時候，就該minicoredump登場了，將現場信息先篩選一遍。工作量優化了不說，對正常生產影響也可以降到最小。”
青囊在一旁，欽佩地望著狄老大，默默地把minicoredump收錄到sysAK里。這里面不僅有內存泄漏定位秘籍，網絡診斷利器，如今還有minicoredump加持，還可以有效地過濾過濾匿名頁信息，對core文件進行瘦身，妙哉妙哉！
舉個栗子
如下表所示，這個是一個典型的案發現場信息分布。minicoredump會針對性地進行收集：標紅的區間需要收集起來，借助于gdb，就可以幫我們將案發過程回放（打調用棧）和關鍵物證提取（獲取棧上變量、全局變量等信息），而標綠的區域可以在必要的時候再收集，不影響我們斷案。
103249: ./main
0000000000400000 4K r-x-- main
0000000000600000 4K r---- main
0000000000601000 4K rw--- main #可執行文件的data段
0000000001fa5000 132K rw--- [ anon ] #堆空間
00007f8188000000 10372K rw--- [ anon ]
00007f8188a21000 55164K ----- [ anon ]
00007f8190000000 10372K rw--- [ anon ]
……
00007f819ca21000 55164K ----- [ anon ]
00007f81a0000000 10372K rw--- [ anon ]
00007f81a0a21000 55164K ----- [ anon ]
00007f81a495d000 4K ----- [ anon ]
00007f81a495e000 8192K rw--- [ anon ] #棧空間
00007f81a6dfe000 10244K rw--- [ anon ]
00007f81a77ff000 4K ----- [ anon ]
00007f81a7800000 8192K rw--- [ anon ]
00007f81a8000000 10372K rw--- [ anon ]
00007f81a8a21000 55164K ----- [ anon ]
00007f81ac15c000 4K ----- [ anon ]
00007f81ac15d000 8192K rw--- [ anon ]
00007f81ac95d000 4K ----- [ anon ]
00007f81ac95e000 8192K rw--- [ anon ]
……
00007f81ae160000 4K ----- [ anon ]
00007f81ae161000 8192K rw--- [ anon ]
00007f81ae961000 1808K r-x-- libc-2.17.so
00007f81aeb25000 2044K ----- libc-2.17.so
00007f81aed24000 16K r---- libc-2.17.so
00007f81aed28000 8K rw--- libc-2.17.so #so data段
00007f81aed2a000 20K rw--- [ anon ] #so BSS段
00007f81aed2f000 92K r-x-- libpthread-2.17.so
00007f81aed46000 2044K ----- libpthread-2.17.so
00007f81aef45000 4K r---- libpthread-2.17.so
00007f81aef46000 4K rw--- libpthread-2.17.so
00007f81aef47000 16K rw--- [ anon ]
00007f81aef4b000 136K r-x-- ld-2.17.so
00007f81af159000 12K rw--- [ anon ] #so link map
00007f81af169000 12K rw--- [ anon ]
00007f81af16c000 4K r---- ld-2.17.so
00007f81af16d000 4K rw--- ld-2.17.so
00007f81af16e000 4K rw--- [ anon ]
00007fff7eafc000 132K rw--- [ stack ]
00007fff7eb58000 8K r---- [ anon ]
00007fff7eb5a000 8K r-x-- [ anon ]
ffffffffff600000 4K r-x-- [ anon ] #syscall
total 532892K
實際表現
該要拿真實數據說話：我們挑了一個真實的環境對比。同樣的進程coredump，文件大小從3.5G下降到了1.9G。
coredump空間縮小后，不影響推棧等功能：
在更為復雜的生產環境，實際優化幅度可以達到80%以上，業務抖動下降了30%。換句話說，在引用了新技術以后，封鎖量減少，交通也就更順暢了。
狄公問：元芳，此法可好？
元芳連連點頭，嘖嘖稱贊：minicoredump神也神也，狄公了不得、了不得啊！
作為高級助理的青囊，站在一旁，用衣袖一遍一遍擦拭羅盤，心里也樂開了花。半年后，狄公和元芳一行在清理大理寺檔案庫房，眼前已然不是堆疊成山的卷宗。得益于變薄的新卷宗，還騰挪出了一方天地，品茶說案，心曠神怡。
狄公戲問——
在一旁的青囊正要開心，突然斥候送來一份搪報，狄公拆開看了，說道：官道上剛出了樁大案，影響甚大，我們要馬上出發。青囊一驚，從夢中醒來，尋思著：官道？難道是新出了網絡問題。欲知后事如何，且聽下回分解。
