13 bug的时间属性周期特点与非规律性.pdfVIP

2018/8/31 极客时间 | 程序员进阶攻略 好多年前，我才刚参加工作不久，就碰到这么一个周期性出现的 Bug。但它的特殊之处在于， 出现 Bug 的程序已经稳定运行了十多年了，突然某天开始就 （进程 Crash）了。而程序的 原作者，早已不知去向，十多年下来想必也已换了好几代程序员来维护了。 一开始项目组内经验老到的高工认为也许这只是一个意外 ，毕竟这个程序已经稳定运行了十 来年了，而且检查了一遍程序编译后的二进制文件，更新时间都还停留在那遥远的十多年前。所 以，我们先把程序重启起来让业务恢复，重启后的程序又恢复了平稳运行，但只是安稳了这么一 天，第二天上班没多久，进程又莫名地 了，我们再次重启，但没多久后就又 了。这下没 人再怀疑这是意外了，肯定有 Bug。 当时想想能找出一个隐藏了这么多年的 Bug，还挺让人兴奋的，就好像发现了埋藏在地下久远 的宝藏。 寻找这个 Bug 的过程有点像《盗墓笔记》中描述的盗墓过程：项目经理（三叔）带着两个高级 工程师（小哥和胖子）连续奋战了好几天，而我则是个新手，主要负责 “看门”，在他们潜入 跟踪分析探索的过程中，我就盯着那个随时有可能 的进程，一崩掉就重启。他们“埋伏”在 那里，系统 后抓住现场，定位到对应的源代码处，最后终于找到了原因并顺利修复。 依稀记得，最后定位到的原因与网络连接数有关，也是属于资源泄漏的一种，只是因为过去十来 年交易量一直不大且稳定，所以没有显现出来。但在我参加工作那年（2006 年），中国股市悄 然引来一场有史以来最大的牛市，这个处理银行和证券公司之间资金进出的程序的“工作量”突 然出现了爆发性增长，从而引发了该 Bug。 我可以理解上世纪九十年代初那个编写该服务进程的程序员，他可能也难以预料到当初写的用者 寥寥的程序，最终在十多年后的一天会服务于成百上千万的用户。 周期性的 Bug，虽然乍一看很难解决的样子，但它总会重复出现，就像可以重新倒带的 “案发 现场”，找到真凶也就简单了。案例中这个 Bug 隐藏的时间很长，但它所暴露出的周期特点很 明显，解决起来也就没那么困难。 其实主要麻烦的是那种这次出现了，但不知道下次会在什么时候出现的 Bug。 非规律性 没有规律性的 Bug，才是让人抓狂的。 曾经我接手过一个系统，是一个典型的生产者、消费者模型系统。系统接过来就发现一个比较明 显的性能瓶颈问题，生产者的数据源来自数据库，生产者按规则提取数据，经过系统产生一系列 的转换渲染后发送到多个外部系统。这里的瓶颈就在数据库上，生产能力不足，从而导致消费者 饥饿。 /column/article/14528 2/6 2018/8/31 极客时间 | 程序员进阶攻略 问题比较明显，我们先优化 SQL，但效果不佳，遂改造设计实现，在数据库和系统之间增加一 个内存缓冲区从而缓解了数据库的负载压力。缓冲区的效果，类似大河之上的堤坝，旱时积水， 涝时泄洪。引入缓冲区后，生产者的生产能力得到了有效保障，生产能力高效且稳定。 本以为至此解决了该系统的瓶颈问题，但在生产环境运行了一段时间后，系统表现为速度时快时 慢，这时真正的 Bug 才显形了。 这个系统有个特点，就是 I/O 密集型。消费者要与多达 30 个外部系统并发通信，所以猜测极有 可能导致系统性能不稳定的 Bug 就在此，于是我把目光锁定在了消费者与外部系统的 I/O 通信 上。既然锁定了怀疑区域，接下来就该用证据来证明，并给出合理的解释原因了。一开始假设在 某些情况下触碰到了阈值极限，当达到临界点时程序性能则急剧下降，不过这还停留在怀疑假设 阶段，接下来必须量化验证这个推测。 那时的生产环境不太方便直接验证测试，我便在测试环境模拟。用一台主机模拟外部系统，一台 主机模拟消费者。模拟主机上的线程池配置等参数完全保持和生产环境一致，以模仿一致的并发 数。通过不断改变通信数据包的大小，发现在数据包接近 100k 大小时，两台主机之间直连