一行代码引发的 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