8

最近我们开始使用 YJP 11.0.9 对我们的应用程序（基于 XMPP 的聊天服务器）进行压力测试。在我们的测试中，我们注意到以下奇怪的行为。

  1. 采样显示 sun.misc.Unsafe.unpark(Object) 占用了 60% 的 CPU。
  2. 对于同一个应用程序跟踪显示 LockSupport.park(Object) 占用了 52% 的 CPU。

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

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

有人可以帮我理解这些结果。我在这里错过了什么吗？

环境：

java版本
java版本“1.6.0_31”
Java(TM) SE 运行时环境 (build 1.6.0_31-b04)
Java HotSpot(TM) 64 位服务器 VM（内部版本 20.6-b01，混合模式）
4

3 回答 3

11

高 CPU 时间是上下文切换Unsafe.unpark过多的标志。这是一篇文章来了解上下文切换的成本：

进行上下文切换需要多长时间？

在 Linux 上找出 CS 计数的最简单的选项是 run vmstat <seconds>。

一旦高 CS 被确认（例如每核/每秒更多 10K 开关），您将使用有问题的线程（您可以在 YJP 中按 CPU 时间对线程进行排序）并运行strace -p <pid> -c以找出切换的原因，例如线程正在从套接字中读取小块并关闭，在这种情况下增加套接字缓冲区可能会有所帮助。

于 2015-04-02T13:47:13.343 回答
3

对于某些低级别的阻塞命令，如读/写/停放/锁定，“CPU”时间被高估了，因为它假设它在实际操作阻塞时正在消耗 CPU。unpark/park 都很高的事实确实表明您有问题，但我怀疑您应该将这两个百分比中的较低者作为估计值。

于 2012-10-19T11:58:31.493 回答
0

I learned the hard way that you can also have high CPU usage % on LockSupport.parkNanos() if you call multiple times the method and your sleep argument is in the order of nanoseconds:

while(true){
  // code logic
  LockSupport.parkNanos(100);
}

Simply changing to microseconds helped me resolve my issue. I also tried it on my local machine and was able to reproduce the high CPU usage %, and saw it drastically improve after going for microseconds.

于 2021-09-10T18:07:38.803 回答