问题
Recently we started stress testing our application (an XMPP based chat server) using YJP 11.0.9. During our test we noticed following strange behavior.
- Sampling shows sun.misc.Unsafe.unpark(Object) took 60% of CPU.
- For the same app Tracing shows that LockSupport.park(Object) took 52% of CPU.
I did multiple tests to confirm results and every time I got similar results.
I am unable to understand why unpark should take 60% time and why tracing shows exactly opposite results.
Can someone help me understand these results. Am I missing something here?
Environment:
java -version java version "1.6.0_31" Java(TM) SE Runtime Environment (build 1.6.0_31-b04) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
回答1:
High CPU time of Unsafe.unpark is a sign of excessive Context Switching. Here is an article to get the idea of how expensive is a context switch:
How long does it take to make a context switch?
The easiest option to find out CS count on Linux is run vmstat <seconds>.
Once high CS is confirmed (e.g. more 10K switches per core/per second) you take the offending thread (you can sort threads in YJP by their CPU time) and run strace -p <pid> -c to find out the cause of switching, e.g. thread is reading from socket in small pieces and get's switched off, in which case increasing socket buffer might help.
回答2:
With certain low level blocking commands like read/write/park/lock the "CPU" time is over estimated as it assumes it is consuming CPU when actually the operation is blocking. The fact unpark/park are both high does suggest you have a problem, but I suspect you should take the lower of the two percentages as an estimate.
来源：https://stackoverflow.com/questions/12972918/why-does-park-unpark-have-60-cpu-usage