性能优化的方法和技巧:工具
作者 kernelchina | 2011-04-21 07:37 | 类型 行业动感 | 27条用户评论 »
系列目录 性能优化方法和技巧“工欲善其事,必先利其器”(孔子),虽然“思想比工具更重要”(弯曲网友),但是,如果没有工具支持,性能优化就会非常累。思想不好掌握,但是使用工具还是比较好学习的,有了工具支持,可以让初级开发者更容易入门。 性能优化用到的工具,需要考虑哪些方面的问题? 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)帮助验证优化方案。优化的结果应该能在工具里面体现出来,而不是靠蒙。 就这些了,还有什么补充? 参考资料 2) http://www.celinuxforum.org/CelfPubWiki/KernelInstrumentation | |
雁过留声
“性能优化的方法和技巧:工具”有27个回复
>>1)帮助建立基线。没有基线,就没办法做性能优化。性能优化是个迭代的过程,指望一次搞定是不现实的。
写的不错。有点我俗家弟子的样子了。。。
华为的?
需要量化的时候,第一件事是拿perf monitor弄出IPC来。其他的东东再说
没有valgrind?
有针对多核调优的利器么?
工具方面可以再补充一下,还有几个大牌没提到:
1. Oracle Solaris Studio
2. IBM Performance inspector
3. Intel VTune
>>>工具方面可以再补充一下,还有几个大牌没提到:
>>>1. Oracle Solaris Studio
>>>2. IBM Performance inspector
>>>3. Intel VTune
你这几个好是好,都是要不少米的呀
收费的只有Intel VTune,不过也可以试用30天
弯友的力量是巨大的,这些工具我都没见过,能看到的基本都是开源,免费的工具,每个人都能看到,都能用。
一般公司对性能优化有多大的投入?感觉web优化,database优化等用途更广泛一点,kernel优化很少见,大部分应用程序优化好像不怎么重视。
性能优化其实是相当于武打小说里面的内功修炼。
同样的功夫套路,内功深厚的人打起来威力就大。
很多表演性质的武术从业者,没有人看他内功的。
1、欧洲的prism,工具很不错;
2、基于硬件仿真的思路进行优化是一个很好的方向;
3、基于系统的应用架构优化其实是最常用也是最有效的方法;
另外,一个问题:
没有用过Linux performance counter,不过,从你的定义来看,“用于收集CPU的performance counter” 好像不大对吧; 众所周知,oProfile是使用了CPU的硬件性能寄存器,这个东东和你的“CPU的performance counter”不是一个概念? 看了一下连接,好像这个只是OS的kernel资源分配计数器吧,跟CPU的应该不是一个概念
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/tools/perf/design.txt?a=ppc
performance counter和Oprofile是两个工具,用法不一样。
我觉得还可以继续分类,比如按功能分:
1. Application Level
2. System Level
3. Kernel Level
4. Chip Level
按实现分:
1. Instrumentation based
2. Sample based
3. Simulation based
>>>一般公司对性能优化有多大的投入?感觉web优化,database优化等用途更广泛一点,kernel优化很少见,大部分应用程序优化好像不怎么重视。
做驱动的就要投入兵力搞优化.user level和kernel level都要.
intel VTune用过但是不是很顺手,cpu级别了都。
solaris studio传说中很虎,用过,linux上面标示施展空间还不如原生的一些内核工具。
IBM的inspector有机会尝试下。
无论怎样,工欲善其事,必先利其器,抱着了解了解的态度去使用工具获得的不过皮毛,真正的了解工具才能了解内部,运用工具,改造工具,发明新的工具,这才算是一大进步
驱动优化是必需的,panabit这方面做的不错。
intel VTune我也使过,CPU级别的,条目太多了,而且不同cpu的描述还有点不一样。呵呵~~,不过有一点好处,对软件性能本身影响并不大。曾经也用过某公司的性能测试工具,几分钟的性能测试,上午测上的,到中午才终于难道了性能分析报告,当时就是面如菜色!
尽管程序员专业的思考始终是核心,工具的一些明显缺陷也很大程度上影响效率,如:
1、不能在产品环境安全的使用,不需重构环境;
2、不能跨越软件层发挥获取和整合信息,如内核/用户边界,进程间边界,java vm边界/jni等。
solaris dtrace在这方面令人耳目一新(也是我印象最为深刻的软件之一,另一个是solaris 10),远比intel vtune等作用大得多,业界已经有很多成功的应用案例。
其关键设计理念可参考acm queue文章,推荐阅读:
http://queue.acm.org/detail.cfm?id=1117401
终于在x86上达到64bit转发线速了! 发现linux协议栈效率太低了!
performance counter 一般是指 CPU 内部的 performance counter 寄存器,一般都能对 Cache Miss,TLB Miss, Branch mis-predicted 等等这些性能敏感事件进行计数。
Oprofile 和 内核新引入的 perf (即 kernelchina 所谓 performance counter 工具)都使用了performance counter 寄存器
oprofile 出现的早,要成熟些。虽也能分析内核,但个人感觉其长于分析用户态的应用
perf 与内核结合紧密,用户态的工具封装的不错,使用方便,个人觉得长于分析内核
同意楼上的! 其实都读取的pc寄存器!感觉要做优化首先就要做代码裁减,多余的代码都是要占用cycle的!
>>>oprofile 出现的早,要成熟些。虽也能分析内核,但个人感觉其长于分析用户态的应用
>>>perf 与内核结合紧密,用户态的工具封装的不错,使用方便,个人觉得长于分析内核
个人觉得,oprofile更好用.对于没有performance counter的处理器(如一些非intel的x86处理器),用timer trigger时oprofile至少不会影响正在剖分的应用,而perf的破坏性更大.
VTUNE我在学校的时候用过,试用版的,做的还是不错,什么函数调用关系等等都很清晰,bottleneck都检测得不错。不过现在我们主要是profile打天下了,这年头开源的工具越做越强大了。
valgrind主要是检测内存泄露的吧?
》》》valgrind主要是检测内存泄露的吧?
哪只是valgrind里面的Memchecker。
还有
Cachegrind和Callgrind
Cachegrind: a cache and branch-prediction profiler
Callgrind: a call-graph generating cache and branch prediction profiler
那天聚会我就一个劲儿地想问性能测量工具,这个东西给力啊
jprobe….虽然和性能优化无关,
却是工具的工具。动态集成到内核。
blktrace..io性能的优化。
从应用角度调优虽然看起来要技术含量低那么一点,但却是容易见到较大效果的做法。这也是很多应用开发人员、DBA谋生的途径之一。性能要结合具体应用才更有价值,更容易找到突破之道。
有时,在应用中发现的性能瓶颈看起来很搞笑,例如分区不对齐、数据库表不建索引等。
思路清晰,特别是对于性能瓶颈的筛查,但总体感觉太泛。 不适合具体讨论。 比如router/nas/database, 性能优化虽有相互借鉴的地方,但从总体看性能优化的方案和思路任有较大差别。