以前做过profile,但是从来没有仔细研究过,最近在一次调优之中,对performance有了很深的认识。详细来研究一下。对于java的profile,可以分为简单的profile和run time的profile。
1.简单的profile:
可以制定目标,看看程序到底慢在哪里。一般不会涉及到程序逻辑的调优与架构的更改。目的就是在真实的应用deploy的时候,对jvm参数进行调优。这里主要可以调的就是gc,使用那个gc算法,以及对gc算法进行具体的优化。对于server端的程序而言,一般都是需要高吞吐率,这样一般都会使用并行gc,在这里需要限制gc线程个数,因为默认的话,会启动n-1个线程,这样可能造成竞争与资源浪费。具体调成几个,需要根据应用以及硬件环境来看。第二个需要调heap的大小,这个一般调调就可以了,比较重要的是,根据per request的机制,或者应用的场景,需要对young generation或者old generation进行调优,一般来讲我们都不希望发生full gc,或者出现young generation分配不了,而频繁的进行PSYoung,我发现这个时候,基本上就会lock住相应的heap part,而应用基本上处于停止状态。对于young generation停止的状况,需要对young的初始大小进行优化,观察应用,适当的调整-XX:NewSize,使得初始值足够使用,这样就不会发生停顿现象。
2.run time profile
这里主要针对程序速度慢来说的,也就是response time。主要原理就是找hot spot,哪里是hot spot就改哪里。也比较有可能的是1.有lock contention导致cpu利用率居高不下,这是可以考虑lock free,或者缩短lock的时间。2.大量临时对象,导致剧烈的gc。这个可能需要看去调gc,或者可以使用对象池之类的技术。
实际上java的profile是基于agent的,参考:
http://java.sun.com/developer/technicalArticles/Programming/HPROF.html
可以针对cpu, heap, monitor进行profile。
看了之后,对profile有了一些认识:
1.cpu=samples,基本上主要用这个,他并不是你调用了多少次方法的samples,而是当前stack的active frame上进行查找的,所以说基本上这个在前面的,可以认为时间比较长。
2.具体的可以通过cpu=times来verify一下,看看到底是不是时间很长。
3.在查看是哪个对象分配了内存的时候,觉得通过heap=sites,thread=y很方便。
4.monitor=y可以看lock的竞争,ms只能看synchronized块,也就是monitor enter,而concurrent包中的Lock目前还不能。估计只能通过人肉了。
目前只研究到这么多。
转自:http://hi.baidu.com/jeffeyliu/blog/item/535ec3afd2b150edfaed5055.html :D
1.简单的profile:
可以制定目标,看看程序到底慢在哪里。一般不会涉及到程序逻辑的调优与架构的更改。目的就是在真实的应用deploy的时候,对jvm参数进行调优。这里主要可以调的就是gc,使用那个gc算法,以及对gc算法进行具体的优化。对于server端的程序而言,一般都是需要高吞吐率,这样一般都会使用并行gc,在这里需要限制gc线程个数,因为默认的话,会启动n-1个线程,这样可能造成竞争与资源浪费。具体调成几个,需要根据应用以及硬件环境来看。第二个需要调heap的大小,这个一般调调就可以了,比较重要的是,根据per request的机制,或者应用的场景,需要对young generation或者old generation进行调优,一般来讲我们都不希望发生full gc,或者出现young generation分配不了,而频繁的进行PSYoung,我发现这个时候,基本上就会lock住相应的heap part,而应用基本上处于停止状态。对于young generation停止的状况,需要对young的初始大小进行优化,观察应用,适当的调整-XX:NewSize,使得初始值足够使用,这样就不会发生停顿现象。
2.run time profile
这里主要针对程序速度慢来说的,也就是response time。主要原理就是找hot spot,哪里是hot spot就改哪里。也比较有可能的是1.有lock contention导致cpu利用率居高不下,这是可以考虑lock free,或者缩短lock的时间。2.大量临时对象,导致剧烈的gc。这个可能需要看去调gc,或者可以使用对象池之类的技术。
实际上java的profile是基于agent的,参考:
http://java.sun.com/developer/technicalArticles/Programming/HPROF.html
可以针对cpu, heap, monitor进行profile。
java -Xrunhprof:help
Option Name and Value Description Default
--------------------- ----------- -------
heap=dump|sites|all heap profiling all
cpu=samples|times|old CPU usage off
monitor=y|n monitor contention n
format=a|b text(txt) or binary output a
file=<file> write data to file java.hprof[{.txt}]
net=<host>:<port> send data over a socket off
depth=<size> stack trace depth 4
interval=<ms> sample interval in ms 10
cutoff=<value> output cutoff point 0.0001
lineno=y|n line number in traces? y
thread=y|n thread in traces? n
doe=y|n dump on exit? y
msa=y|n Solaris micro state accounting n
force=y|n force output to <file> y
verbose=y|n print messages about dumps y
Obsolete Options
----------------
gc_okay=y|n
Examples
--------
- Get sample cpu information every 20 millisec, with a stack depth of 3:
java -agentlib:hprof=cpu=samples,interval=20,depth=3 classname
- Get heap usage information based on the allocation sites:
java -agentlib:hprof=heap=sites classname
Notes
-----
- The option format=b cannot be used with monitor=y.
- The option format=b cannot be used with cpu=old|times.
- Use of the -Xrunhprof interface can still be used, e.g.
java -Xrunhprof:[help]|[<option>=<value>, ...]
will behave exactly the same as:
java -agentlib:hprof=[help]|[<option>=<value>, ...]
Warnings
--------
- This is demonstration code for the JVMTI interface and use of BCI,
it is not an official product or formal part of the JDK.
- The -Xrunhprof interface will be removed in a future release.
- The option format=b is considered experimental, this format may change
in a future release.
看了之后,对profile有了一些认识:
1.cpu=samples,基本上主要用这个,他并不是你调用了多少次方法的samples,而是当前stack的active frame上进行查找的,所以说基本上这个在前面的,可以认为时间比较长。
2.具体的可以通过cpu=times来verify一下,看看到底是不是时间很长。
3.在查看是哪个对象分配了内存的时候,觉得通过heap=sites,thread=y很方便。
4.monitor=y可以看lock的竞争,ms只能看synchronized块,也就是monitor enter,而concurrent包中的Lock目前还不能。估计只能通过人肉了。
目前只研究到这么多。
转自:http://hi.baidu.com/jeffeyliu/blog/item/535ec3afd2b150edfaed5055.html :D