在一个风和日丽的下午，我喝着咖啡敲着代码，突然就接到平台组测出来这个这次TDengine发版的性能比上次发版的性能下降了不少，然后就是自然而然甩锅接锅的环节，当锅甩到我头上的时候，我是不以为然的，自认为我的几个改动的提交怎么会影响性能？所以理所当然的去revert掉我的几次提交，然后再测一下性能。结果好巧不巧，测试用例本身就是概率性复现性能问题，结果我revert掉测试刚好没有发现性能问题，此时的我更加理直气壮了，这肯定不是我的锅啊！
但是甩锅要讲究一个证据确凿，虽然我确定了问题不在我身上，但是也不能甩回去让平台组的人来找下一个倒霉蛋吧，所以我还是决定亲自测一下是哪次提交导致的性能问题，没想到就此踏上了一条绝望之路
顶着不稳定复现，以及性能差异过于微小（微小到一点点硬件性能波动就会掩盖掉性能问题）的痛苦，查了好久终于定位到了一次提交，居然是一个merge！这让我十分困惑，先将main合进自己的分支（fix/TD-33600），之后又将合并后的分支merge到main分支，就出问题了？那肯定是自己的修改导致的，所以我就找了本次提交的同事去排查问题。
本以为锅甩出去了，结果过了一会又被甩回来了，并且让我哑口无言，上面和下面的两次提交之间的那个merge，有n次提交，用git log排查发现上下两次提交，虽然时间上前后关系，但是版本却差了十万八千里！
git log --graph --decorate --oneline
下图TD-33600那个分支是从很早以前从main分支上checkout出去的，所以在c3c2dcf522这次merge之前，main分支上所有的提交都没有在TD-33600分支上呈现，所以改次提交虽然时间很靠后，但是其实它的版本十分靠前，通过一次merge main分支的操作追上了main的版本，但是这次合并引入和太多的提交，需要通过Gitlens工具再去详细划分。
最终查出来还是我写出来的bug，苍天绕过谁啊…….
通过这次问题，我反思了一下：
- 因为之前我习惯使用git rebase和git cherry-pick来提交代码，不喜欢merge来解决无尽的冲突，导致突然看到merge对于分支的时许一下子没反应过来，犯了如此低级的错误，真是不应该啊。
- 其次还有一个误导性很强的提交，就是最下面那个fix windows提交，虽然时间是1月23日，但实际上它的版本远远落后于main分支，起码是1月19日，不能通过提交时间判断实际的分支版本。
- 还有就是那个该死的不稳定的性能测试脚本，以后但凡是测试脚本不能稳定复现，或者测试时间长度不合理，一定要先改测试，否则会浪费成百上千的时间在无意义的测试执行上。
- 最终硬件选择上也需要提升可靠性，比如用物理机而非虚拟机、排除其他程序的干扰、将数据挂在的盘从hdd换成ssd
顺便一提，本次性能问题是一个线程同步方式引起的，如果你对于这块内容感兴趣，可以关注我之前的文章：线程同步方式的对响应速度影响这么大？
最后打个广告，了解开源时序数据库TDengine 更多内容欢迎访问：TDengine
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
