性能优化的方法和技巧:工具

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




“工欲善其事,必先利其器”(孔子),虽然“思想比工具更重要”(弯曲网友),但是,如果没有工具支持,性能优化就会非常累。思想不好掌握,但是使用工具还是比较好学习的,有了工具支持,可以让初级开发者更容易入门。

性能优化用到的工具,需要考虑哪些方面的问题?

1)使用工具是否需要重新编译代码?

  一般来说,性能优化工具基本上都需要重新编译代码。因为在生产环境里面使用的image,应该是已经优化过的image。不应该在用户环境里面去调试性能问题。但Build-in的工具有一个好处就是性能测试所用的image和性能调试所用的image是相同的,这样可以避免重新编译所带来的误差。

2)工具本身对测量结果的影响

  如果是Build-in的工具,需要减小工具对性能的影响,启用工具和不启用工具对性能的影响应该在一定范围之内,比如5%,否则不清楚是工具本身影响性能还是被测量的代码性能下降。

  如果是需要重新编译使用的工具,这里的测试是一个相对值,不能做为性能指标的依据。因为编译会修改代码的位置,也可能会往代码里面加一个测量函数,它生成的image和性能测试的image不一样。

在这里要列出几个我用过的Linux工具,其他系统应该也有对应的工具,读者可以自己搜索。

性能测试工具一般分这么几种

1)收集CPU的performance counter。CPU里面有很多performance counter,打开之后,会记录CPU某些事件的数量,比如cache miss, 指令数,指令时间等等。这些counter需要编程才能使用。测量哪一段代码完全由自己掌握。

2)利用编译器的功能,在函数入口和出口自动加回调函数,在回调函数里面,记录入口和出口的时间。收集这些信息,可以得到函数的调用流程和每个函数所花费的时间。

3)自己在代码里面加入时间测量点,测量某段代码执行的时间。这种工具看起来和#1的作用差不多,但是由于performance counter编程有很多限制,所以这种工具有时还是有用处的。

在Linux里面,我们经常会用到

1)Oprofile

Oprofile已经加入了linux的内核代码库,所以不需要打patch,但是还需要重新编译内核才可以使用。这是使用最广泛的linux工具,网上有很多使用指南,读者可以自己搜索参考。

http://oprofile.sourceforge.net/news/

http://people.redhat.com/wcohen/Oprofile.pdf

2) KFT and Gprof

KFT是kernel的一个patch,只对kernel有效;Gprof是gcc里面的一个工具,只对用户空间的程序有效。这两个工具都需要重新编译代码,它们都用到了gcc里面的finstrument-functions选项。编译时会在函数入口,出口加回调函数,而且inline函数也会改成非inline的。它的工作原理可以参考:

http://blog.linux.org.tw/~jserv/archives/001870.html

http://blog.linux.org.tw/~jserv/archives/001723.html

http://elinux.org/Kernel_Function_Trace

http://www.network-theory.co.uk/docs/gccintro/gccintro_80.html

个人认为这是一个非常有用的工具,对读代码也有帮助,是居家旅行的必备。这里还有一个slide比较各种工具的,可以看看。

3) Performance counter

http://anton.ozlabs.org/blog/2009/09/04/using-performance-counters-for-linux/

Linux performance counter,用于收集CPU的performance counter,已经加入了内核代码库。通常来说,performance counter的粒度太大,基本没有什么用处,因为没法定位问题出在哪里;如果粒度太小,就需要手工编程,不能靠加几个检查点就可以了。所以还是要结合上面两个工具一起用才有好的效果。

工具解决哪些问题?

1)帮助建立基线。没有基线,就没办法做性能优化。性能优化是个迭代的过程,指望一次搞定是不现实的。

2)帮助定位问题。这里有两个涵义:一是性能问题出现在什么地方,是由哪一段代码引起的;二是性能问题的原因,cache miss,TLB miss还是其他。

3)帮助验证优化方案。优化的结果应该能在工具里面体现出来,而不是靠蒙。

就这些了,还有什么补充?

参考资料

1)http://software.intel.com/en-us/articles/intel-microarchitecture-codename-nehalem-performance-monitoring-unit-programming-guide/

2)  http://www.celinuxforum.org/CelfPubWiki/KernelInstrumentation

3)  Continuous Profiling: Where Have All the Cycles Gone?

(2个打分, 平均:5.00 / 5)

雁过留声

“性能优化的方法和技巧:工具”有27个回复

  1. 陈怀临 于 2011-04-21 7:39 上午

    >>1)帮助建立基线。没有基线,就没办法做性能优化。性能优化是个迭代的过程,指望一次搞定是不现实的。

    写的不错。有点我俗家弟子的样子了。。。

  2. 华龙 于 2011-04-21 8:36 上午

    华为的?

  3. kevin 于 2011-04-21 1:32 下午

    需要量化的时候,第一件事是拿perf monitor弄出IPC来。其他的东东再说

  4. westermann 于 2011-04-21 2:47 下午

    没有valgrind?

  5. sieie 于 2011-04-21 5:21 下午

    有针对多核调优的利器么?

  6. Yichun Wang 于 2011-04-21 7:58 下午

    工具方面可以再补充一下,还有几个大牌没提到:
    1. Oracle Solaris Studio
    2. IBM Performance inspector
    3. Intel VTune

  7. westermann 于 2011-04-21 8:02 下午

    >>>工具方面可以再补充一下,还有几个大牌没提到:
    >>>1. Oracle Solaris Studio
    >>>2. IBM Performance inspector
    >>>3. Intel VTune

    你这几个好是好,都是要不少米的呀

  8. Yichun Wang 于 2011-04-21 8:05 下午

    收费的只有Intel VTune,不过也可以试用30天

  9. kernelchina 于 2011-04-21 8:22 下午

    弯友的力量是巨大的,这些工具我都没见过,能看到的基本都是开源,免费的工具,每个人都能看到,都能用。
    一般公司对性能优化有多大的投入?感觉web优化,database优化等用途更广泛一点,kernel优化很少见,大部分应用程序优化好像不怎么重视。

  10. 文海 于 2011-04-21 9:04 下午

    性能优化其实是相当于武打小说里面的内功修炼。
    同样的功夫套路,内功深厚的人打起来威力就大。
    很多表演性质的武术从业者,没有人看他内功的。

  11. Sting 于 2011-04-21 9:28 下午

    1、欧洲的prism,工具很不错;
    2、基于硬件仿真的思路进行优化是一个很好的方向;
    3、基于系统的应用架构优化其实是最常用也是最有效的方法;

    另外,一个问题:
    没有用过Linux performance counter,不过,从你的定义来看,“用于收集CPU的performance counter” 好像不大对吧; 众所周知,oProfile是使用了CPU的硬件性能寄存器,这个东东和你的“CPU的performance counter”不是一个概念? 看了一下连接,好像这个只是OS的kernel资源分配计数器吧,跟CPU的应该不是一个概念

  12. kernelchina 于 2011-04-21 10:04 下午

    http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/tools/perf/design.txt?a=ppc

    performance counter和Oprofile是两个工具,用法不一样。

  13. Yichun Wang 于 2011-04-21 10:09 下午

    我觉得还可以继续分类,比如按功能分:
    1. Application Level
    2. System Level
    3. Kernel Level
    4. Chip Level
    按实现分:
    1. Instrumentation based
    2. Sample based
    3. Simulation based

  14. westermann 于 2011-04-21 10:28 下午

    >>>一般公司对性能优化有多大的投入?感觉web优化,database优化等用途更广泛一点,kernel优化很少见,大部分应用程序优化好像不怎么重视。

    做驱动的就要投入兵力搞优化.user level和kernel level都要.

  15. matriz 于 2011-04-21 11:51 下午

    intel VTune用过但是不是很顺手,cpu级别了都。
    solaris studio传说中很虎,用过,linux上面标示施展空间还不如原生的一些内核工具。
    IBM的inspector有机会尝试下。
    无论怎样,工欲善其事,必先利其器,抱着了解了解的态度去使用工具获得的不过皮毛,真正的了解工具才能了解内部,运用工具,改造工具,发明新的工具,这才算是一大进步

  16. maple leaf 于 2011-04-22 1:09 上午

    驱动优化是必需的,panabit这方面做的不错。
    intel VTune我也使过,CPU级别的,条目太多了,而且不同cpu的描述还有点不一样。呵呵~~,不过有一点好处,对软件性能本身影响并不大。曾经也用过某公司的性能测试工具,几分钟的性能测试,上午测上的,到中午才终于难道了性能分析报告,当时就是面如菜色!

  17. anonymous 于 2011-04-22 1:49 上午

    尽管程序员专业的思考始终是核心,工具的一些明显缺陷也很大程度上影响效率,如:
    1、不能在产品环境安全的使用,不需重构环境;
    2、不能跨越软件层发挥获取和整合信息,如内核/用户边界,进程间边界,java vm边界/jni等。

    solaris dtrace在这方面令人耳目一新(也是我印象最为深刻的软件之一,另一个是solaris 10),远比intel vtune等作用大得多,业界已经有很多成功的应用案例。

    其关键设计理念可参考acm queue文章,推荐阅读:
    http://queue.acm.org/detail.cfm?id=1117401

  18. 小飞侠 于 2011-04-22 1:59 上午

    终于在x86上达到64bit转发线速了! 发现linux协议栈效率太低了! 

  19. comcat 于 2011-04-22 2:25 上午

    performance counter 一般是指 CPU 内部的 performance counter 寄存器,一般都能对 Cache Miss,TLB Miss, Branch mis-predicted 等等这些性能敏感事件进行计数。

    Oprofile 和 内核新引入的 perf (即 kernelchina 所谓 performance counter 工具)都使用了performance counter 寄存器

    oprofile 出现的早,要成熟些。虽也能分析内核,但个人感觉其长于分析用户态的应用

    perf 与内核结合紧密,用户态的工具封装的不错,使用方便,个人觉得长于分析内核

  20. 小飞侠 于 2011-04-22 3:10 上午

    同意楼上的! 其实都读取的pc寄存器!感觉要做优化首先就要做代码裁减,多余的代码都是要占用cycle的!

  21. westermann 于 2011-04-22 3:50 上午

    >>>oprofile 出现的早,要成熟些。虽也能分析内核,但个人感觉其长于分析用户态的应用

    >>>perf 与内核结合紧密,用户态的工具封装的不错,使用方便,个人觉得长于分析内核

    个人觉得,oprofile更好用.对于没有performance counter的处理器(如一些非intel的x86处理器),用timer trigger时oprofile至少不会影响正在剖分的应用,而perf的破坏性更大.

  22. 三千大千世界 于 2011-04-22 5:53 上午

    VTUNE我在学校的时候用过,试用版的,做的还是不错,什么函数调用关系等等都很清晰,bottleneck都检测得不错。不过现在我们主要是profile打天下了,这年头开源的工具越做越强大了。
    valgrind主要是检测内存泄露的吧?

  23. westermann 于 2011-04-22 7:37 上午

    》》》valgrind主要是检测内存泄露的吧?
    哪只是valgrind里面的Memchecker。
    还有
    Cachegrind和Callgrind
    Cachegrind: a cache and branch-prediction profiler
    Callgrind: a call-graph generating cache and branch prediction profiler

  24. rinehart 于 2011-04-25 3:13 上午

    那天聚会我就一个劲儿地想问性能测量工具,这个东西给力啊

  25. 天外有天 于 2011-04-25 4:02 上午

    jprobe….虽然和性能优化无关,
    却是工具的工具。动态集成到内核。

    blktrace..io性能的优化。

  26. zedware 于 2011-04-25 8:46 上午

    从应用角度调优虽然看起来要技术含量低那么一点,但却是容易见到较大效果的做法。这也是很多应用开发人员、DBA谋生的途径之一。性能要结合具体应用才更有价值,更容易找到突破之道。
    有时,在应用中发现的性能瓶颈看起来很搞笑,例如分区不对齐、数据库表不建索引等。

  27. washion 于 2011-05-11 7:05 下午

    思路清晰,特别是对于性能瓶颈的筛查,但总体感觉太泛。 不适合具体讨论。 比如router/nas/database, 性能优化虽有相互借鉴的地方,但从总体看性能优化的方案和思路任有较大差别。