All geek questions in one place

Why does park / unpark have 60% CPU usage?

We recently started stress testing our application (XMPP-based chat server) using YJP 11.0.9. During our test, we noticed the following strange behavior.

  • The sample shows sun.misc.Unsafe.unpark (Object) takes up 60% of the CPU.
  • For the same application, Tracing shows that LockSupport.park (Object) occupies 52% of the CPU.

I did some tests to confirm the results, and every time I got similar results.

I cannot understand why unpark should take 60% of the time and why the trace shows exactly the opposite results.

Can someone help me understand these results. Did I miss something?

Wednesday:

  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)
+6
source share
2 answers

With some low-level lock commands, such as read / write / park / lock, the CPU time is estimated as it is supposed to consume the processor when the operation actually locks. The fact of unpark / park is high, and this suggests that you have a problem, but I suspect you should take the lower of two percent as an estimate.

+3
source

High CPU time Unsafe.unpark is a sign of excessive context switching. Here's an article to understand how expensive a context switch is:

How long does it take to make a context switch?

The easiest way to find out the number of CSs on Linux is to run vmstat <seconds> .

After confirming high CS (for example, more than 10K switches per core per second), you accept an abusive thread (you can sort threads in YJP according to their processor time) and run strace -p <pid> -c to find out the reason for switching, for example . the thread is read from the socket in small parts and disconnected, in which case an increase in the socket buffer may be required.

+3
source

Source: https://habr.com/ru/post/928106/

More articles:


All Articles