“墨菲定律”这样说：“凡事只要有可能出错，那就一定会出错。”
1 问题描述
周五时候，升级通信框架的剥离后，CI主机运行缓慢。增量编译情况下，整个整个流程运行26分钟，以前正常的情况为7-10分钟左右。整个机子卡顿严重。特别是编译环境，单元测试环节，单元测试覆盖率环节延时问题比较严重。对比数据如下:
| 环节 | 正常[单位：秒] | 异常[单位：秒] |
|---|---|---|
| 全量编译 | 313 | 437 |
| 单元测试 | 141 | 977 |
| 单元测试覆盖率 | 106 | 482 |
另外执行单元测试可能存在卡死的情况。卡顿时，抓单元测试堆栈如下：
2 分析解决
2.1 环境因素排查
多个环节同时慢，而且主机卡顿，检查CPU没有变化外，首先还是考虑硬盘问题。集成从监控来看，只说明io读写比较大。自己测试性能，用以下命令测试磁盘读写：
time -p bash -c "(dd if=/dev/zero of=test.dd bs=1M count=3000)"
更有主机的读写达2G/S。为了排除主机因素，集成帮忙将虚拟机迁移到其他主机后，数据有好转，但是问题依然存在。
2.2 软件因素排查
检查gcc gcov lcov版本和变动时间，确保没有变动。
2.3 单元测试并行问题解决
在单元测试并行运行实践时，当时并行时，没有考虑控制并发度。发现虚拟机调度没有问题。这次问题爆发印证了墨菲定律。着手优化，采用管道模式按照CPU数目来进行控制并发度。示例代码如下：
#!/bin/bash
cpu_number=`cat /proc/cpuinfo | grep ^processor | wc -l`
mkfifo fd2
exec 9<>fd2
for((i=0;i<$cpu_number;i++))
do
echo -n -e "1\n" 1>&9
done
for cur_gtest in $gtest_list
do
read -u 9
{
#shell
echo -ne "1\n" 1>&9
}&
done
wait
修改后，运行正常。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“比其他版本多很多。
感觉已经明朗。
2.5 问题明朗解决
| 环节 | 正常[单位：秒] | 异常[单位：秒] | 修复[单位：秒] |
|---|---|---|---|
| 全量编译 | 313 | 437 | 229 |
| 单元测试 | 141 | 977 | 85 |
| 单元测试覆盖率 | 106 | 482 | 90 |
问题解决后提速分析：
1）在IO提速一倍以上，各个环节提速效果明显。
2）单元测试并行执行在有效控制竞争以后，可以提高效率。
问题说明，Splog是利用C++11实现的纯头文件的日志组件，将其加入业务代码通用的头文件，导致问题产生，真的是一行代码引发的惨案。
3 小结
问题解决一波三折，值得总结。个人体会如下：
- 1）VUCA时代，墨菲定律值得重视。
- 2）Clean Code的物理设计需要严格遵守
- 3）以lcov日志为契机，对于代码标准库使用做一个大扫除。
在技术复杂的系统中，每一个问题背后的因果都缺乏可预测性。靠经验未必可取，应该积极分析细节去推敲，找出背后根源。正如此次问题，因为一行头文件引用，而导致编译，测试用例和覆盖率的问题执行效率问题，是超出想象的。
