一行代码引发的 CI 悲剧
“墨菲定律”这样说：“凡事只要有可能出错，那就一定会出错。”
1 问题描述
周五时候，升级通信框架的剥离后，CI主机运行缓慢。增量编译情况下，整个整个流程运行26分钟，以前正常的情况为7-10分钟左右。整个机子卡顿严重。特别是编译环境，单元测试环节，单元测试覆盖率环节延时问题比较严重。对比数据如下:
另外执行单元测试可能存在卡死的情况。卡顿时，抓单元测试堆栈如下：
单元测试
2 分析解决
2.1 环境因素排查
多个环节同时慢，而且主机卡顿，检查CPU没有变化外，首先还是考虑硬盘问题。集成从监控来看，只说明io读写比较大。自己测试性能，用以下命令测试磁盘读写：
time -p bash -c “(dd if=/dev/zero of=test.dd bs=1M count=3000)”
CI主机
其他主机
更有主机的读写达2G/S。为了排除主机因素，集成帮忙将虚拟机迁移到其他主机后，数据有好转，但是问题依然存在。
2.2 软件因素排查
检查gcc gcov lcov版本和变动时间，确保没有变动。
2.3 单元测试并行问题解决
在单元测试并行运行实践时，当时并行时，没有考虑控制并发度。发现虚拟机调度没有问题。这次问题爆发印证了墨菲定律。着手优化，采用管道模式按照CPU数目来进行控制并发度。示例代码如下：
修改后，运行正常。157秒，比以前时间略大。
2.4 覆盖率生成环节排查
从数据看这块性能差距是4倍，需要从这里找到原因。这个环节有两个步骤
lcov -d ~/src —no-external —rc lcov_branch_coverage=1 -c -o test.info genhtml —branch-coverage -o result test.info
从单步测试来看，时间主要花费在lcov环节。 首先考虑升级最新版本lcov，问题依然存在。 CI工具的同事对比其他的环境，发现日志“ignoring data for external file“比其他版本多很多。
lcov日志
感觉已经明朗。
2.5 问题明朗解决
问题定位给
问题解决后提速分析： 1）在IO提速一倍以上，各个环节提速效果明显。 2）单元测试并行执行在有效控制竞争以后，可以提高效率。
问题说明，Splog是利用C++11实现的纯头文件的日志组件，将其加入业务代码通用的头文件，导致问题产生，真的是一行代码引发的惨案。
3 小结
问题解决一波三折，值得总结。个人体会如下：
1）VUCA时代，墨菲定律值得重视。 2）Clean Code的物理设计需要严格遵守 3）以lcov日志为契机，对于代码标准库使用做一个大扫除。
物理设计
在技术复杂的系统中，每一个问题背后的因果都缺乏可预测性。靠经验未必可取，应该积极分析细节去推敲，找出背后根源。正如此次问题，因为一行头文件引用，而导致编译，测试用例和覆盖率的问题执行效率问题，是超出想象的。
作者：通爸
来源：简书 出处：https://www.jianshu.com/p/72d89e213122