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
00000000004000004Kr-x--main
00000000006000004Kr----main
00000000006010004Krw---main#可执行文件的data段
0000000001fa5000132Krw---[anon]#堆空间
00007f818800000010372Krw---[anon]
00007f8188a2100055164K-----[anon]
00007f819000000010372Krw---[anon]
……
00007f819ca2100055164K-----[anon]
00007f81a000000010372Krw---[anon]
00007f81a0a2100055164K-----[anon]
00007f81a495d0004K-----[anon]
00007f81a495e0008192Krw---[anon]#栈空间
00007f81a6dfe00010244Krw---[anon]
00007f81a77ff0004K-----[anon]
00007f81a78000008192Krw---[anon]
00007f81a800000010372Krw---[anon]
00007f81a8a2100055164K-----[anon]
00007f81ac15c0004K-----[anon]
00007f81ac15d0008192Krw---[anon]
00007f81ac95d0004K-----[anon]
00007f81ac95e0008192Krw---[anon]
……
00007f81ae1600004K-----[anon]
00007f81ae1610008192Krw---[anon]
00007f81ae9610001808Kr-x--libc-2.17.so
00007f81aeb250002044K-----libc-2.17.so
00007f81aed2400016Kr----libc-2.17.so
00007f81aed280008Krw---libc-2.17.so#sodata段
00007f81aed2a00020Krw---[anon]#soBSS段
00007f81aed2f00092Kr-x--libpthread-2.17.so
00007f81aed460002044K-----libpthread-2.17.so
00007f81aef450004Kr----libpthread-2.17.so
00007f81aef460004Krw---libpthread-2.17.so
00007f81aef4700016Krw---[anon]
00007f81aef4b000136Kr-x--ld-2.17.so
00007f81af15900012Krw---[anon]#solinkmap
00007f81af16900012Krw---[anon]
00007f81af16c0004Kr----ld-2.17.so
00007f81af16d0004Krw---ld-2.17.so
00007f81af16e0004Krw---[anon]
00007fff7eafc000132Krw---[stack]
00007fff7eb580008Kr----[anon]
00007fff7eb5a0008Kr-x--[anon]
ffffffffff6000004Kr-x--[anon]#syscall
total532892K

实际表现

该要拿真实数据说话：我们挑了一个真实的环境对比。同样的进程coredump，文件大小从3.5G下降到了1.9G。

coredump空间缩小后，不影响推栈等功能：

在更为复杂的生产环境，实际优化幅度可以达到80%以上，业务抖动下降了30%。换句话说，在引用了新技术以后，封锁量减少，交通也就更顺畅了。

狄公问：元芳，此法可好?

元芳连连点头，啧啧称赞：minicoredump神也神也，狄公了不得、了不得啊!

作为高级助理的青囊，站在一旁，用衣袖一遍一遍擦拭罗盘，心里也乐开了花。

半年后，狄公和元芳一行在清理大理寺档案库房，眼前已然不是堆叠成山的卷宗。得益于变薄的新卷宗，还腾挪出了一方天地，品茶说案，心旷神怡。

狄公戏问——

在一旁的青囊正要开心，突然斥候送来一份搪报，狄公拆开看了，说道：官道上刚出了桩大案，影响甚大，我们要马上出发。青囊一惊，从梦中醒来，寻思着：官道?难道是新出了网络问题。欲知后事如何，且听下回分解。(完)

参考内容

https://www.cnblogs.com/lidabo/p/5014710.html

http://hutaow.com/blog/2013/10/25/linux-core-dump/

https://www.cnblogs.com/secondtonone1/p/5732938.html