“墨菲定律”这样说：“凡事只要有可能出错，那就一定会出错。”

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)"

CI主机
其他主机

更有主机的读写达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“比其他版本多很多。

lcov日志

感觉已经明朗。

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日志为契机，对于代码标准库使用做一个大扫除。

物理设计

在技术复杂的系统中，每一个问题背后的因果都缺乏可预测性。靠经验未必可取，应该积极分析细节去推敲，找出背后根源。正如此次问题，因为一行头文件引用，而导致编译，测试用例和覆盖率的问题执行效率问题，是超出想象的。