简介： minicoredump神也！
继上一篇非典型程序员青囊搞定内存泄露问题后，美美地睡了一觉。睡梦中，突然金光闪闪，万道光芒照进时光隧道，恍惚来到大唐神龙年间。青囊此时化身狄仁杰高级助理，陪同狄老大和元芳及千牛卫来到案发现场，一番勘察后迅速锁定真凶。虽整日伏于桌前写代码，但早被生活驯服得谨小慎微、擅于察言观色的青囊亦早已悟透了这断案的奥秘。
只是，站在一旁的元芳眉头紧锁，面露难色......
狄公上前问道：元芳，有心事？
元芳起身答道：“大人断案如神，只是像长安这种要案频繁的地方，每次案发，都要出动上百千牛卫来大面积封锁现场，走访上万群众，耗费人力不说，还严重阻塞交通，影响了正常的生产秩序，导致其它业务部门受损，一直以来是怨声载道啊。”
狄公笑了笑，手指向青囊，“囊啊，给你元芳哥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神也神也，狄公了不得、了不得啊！
作为高级助理的青囊，站在一旁，用衣袖一遍一遍擦拭罗盘，心里也乐开了花。半年后，狄公和元芳一行在清理大理寺档案库房，眼前已然不是堆叠成山的卷宗。得益于变薄的新卷宗，还腾挪出了一方天地，品茶说案，心旷神怡。
狄公戏问——
在一旁的青囊正要开心，突然斥候送来一份搪报，狄公拆开看了，说道：官道上刚出了桩大案，影响甚大，我们要马上出发。青囊一惊，从梦中醒来，寻思着：官道？难道是新出了网络问题。欲知后事如何，且听下回分解。（完）
原文链接
本文为阿里云原创内容，未经允许不得转载。
