本文介绍了为什么park / unpark有60%的CPU使用率?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

最近我们开始使用YJP 11.0.9对我们的应用程序(基于XMPP的聊天服务器)进行压力测试。在我们的测试中,我们发现了以下奇怪的行为。

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.


  1. 采样显示sun.misc.Unsafe.unpark(Object)占用了60%的CPU。

  2. 对于同一个应用程序跟踪显示LockSupport.park(Object)占用了52%的CPU。

我做了多次测试以确认结果,每次我得到类似的结果。

I did multiple tests to confirm results and every time I got similar results.

我无法理解为什么unpark应该花费60%的时间以及为什么跟踪显示正好相反结果。

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?

环境:

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)


推荐答案

高CPU时间 Unsafe.unpark 是过度的迹象上下文切换。这篇文章是为了了解上下文切换的代价是多少:

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:

最简单的选项找出Linux上的CS计数运行 vmstat< seconds>

The easiest option to find out CS count on Linux is run vmstat <seconds>.

一旦确认了高CS(例如,每个核心/每秒更多10K交换机),您就会接受违规线程(您可以按照其CPU时间对YJP中的线程进行排序)并运行 strace -p< pid> -c 以找出切换的原因,例如:线程正在从套接字中读取小块并关闭,在这种情况下,增加套接字缓冲区可能有所帮助。

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.

这篇关于为什么park / unpark有60%的CPU使用率?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-27 07:11