1、确定问题原因:
1)场景复现:方式1:根据现场日志确定问题原因;方式2:压测复现。
存在的问题:方式1:日志中没有保存现场;方式2:压测可能与线上不符;压测可能无法满足某些特殊条件。
2)一些手段:
a.如果问题只在特定机器出现,确定机器硬件配置是否相同,cpu、meminfo、系统配置等;
b.分阶段、逐步细化各步骤的处理时间、队列积压长度等;
c.可以使用一些辅助性能分析工具进行分析,代价是学习成本,场景不一定符合性能分析工具作用的发挥。
最终发现的高qps时,耗时主要集中在信息流配图阶段和it_proc特征收集阶段。
2、分析现象本质:
1)it_proc:
内部循环过多:按照it内部的参数默认值计算,最大循环次数达到百万级别,在其他特征收集基本0ms的情况下,it的耗时是不可接受的。
2)信息流配图:
分阶段、逐步细化各步骤的处理时间并不能发现问题原因,这种情况就不能怀疑单次执行内部函数的耗时上,很有可能是系统在做切换、同步等处理时导致的异常。
对这一部分程序重新研读,发现调用的std标准函数random_shuffle有重大嫌疑,在此怀疑的基础上,注释掉相关代码,确实不再发生同样的问题,问题得到确认。
问题参考资料:
http://www.cplusplus.com/refe...
is-random-shuffle-threadsafe-and-using-rand-r-if-it-is-not
https://github.com/mariusmuja...
3、问题修复方式:
1)it_proc:
和策略同学讨论修复方式,谁开发谁维护的原则,发现是按权重抽样算法过于复杂,最后确定已现有ot的处理方式进行修改;
2)信息流配图:
a. 信息流配图也存在大量循环,首先将不需要再循环内部执行的代码移到循环体外部,其次尽量在不影响功能的情况下降低循环次数。
b.对于random_shuffle的问题,采用基于rand_r自定义随机生成器的方式调用
template void random_shuffle (RandomAccessIterator first, RandomAccessIterator last,RandomNumberGenerator&& gen);
实现数组打散。
4、总结:
1)性能问题排查的思路和步骤(定位问题比解决问题更加困难,无法定位问题就更谈不上解决问题)
2)代码优化的原则:
a.阿姆达尔定律:不经常使用的代码不需要做较多优化考虑,即让经常执行的路径运行更加高效,而运行稀少的路径正确执行。
b.先保证代码的正确性,再考虑优化。
c.优化所需的时间常常是写代码时间的double。
3)优化分为系统级别的优化和代码级别的优化
系统级别的优化常常需要模块或子模块的重构,需要从顶端开始出方案和设计。推荐书目:《重构-改善既有代码的设计》
代码级别的优化更多的是使用一下小技巧实现,如果可以参考这几个链接:
http://www.jb51.net/article/5...
http://blog.csdn.net/wind19/a...
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。