最近,我们开始使用YJP 11.0.9对我们的应用程序(基于XMPP的聊天服务器)进行压力测试。在我们的测试中,我们发现了以下奇怪的行为。
我做了多次测试以确认结果,每次我得到类似的结果。
我无法理解为什么unpark应该花费60%的时间以及为什么跟踪显示完全相反的结果。
有人可以帮我理解这些结果。我在这里错过了什么吗?
环境:
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)
答案 0 :(得分:5)
Unsafe.unpark
的高CPU时间表示过多的上下文切换。这篇文章是关于上下文切换有多昂贵的想法:
How long does it take to make a context switch?
在Linux上查找CS计数的最简单方法是运行vmstat <seconds>
。
一旦确认了高CS(例如每个核心/每秒更多10K交换机),您就会接受违规线程(您可以按照其CPU时间对YJP中的线程进行排序)并运行strace -p <pid> -c
以查找切换原因,例如线程正在从套接字中读取小块并关闭,在这种情况下,增加套接字缓冲区可能有所帮助。
答案 1 :(得分:3)
对于某些低级别阻塞命令(如读/写/停放/锁定),“CPU”时间被过度估计,因为它假设在实际操作阻塞时它正在消耗CPU。事实上unpark / park都很高,这表明你有问题,但我怀疑你应该把两个百分比中较低的一个作为估计。