CPU时间百分比算法问题
我创建的 Java 算法存在问题,该算法用于将纳秒 CPU 时间使用率(通过 JMX 获得)转换为 100% 的百分比。该算法似乎给出了大于 100% 的数字,我认为这是由于多个可用处理器造成的,尽管代码应该解决这个问题。该算法如下所示。 cpuTimeDiffNS
是使用的 CPU 时间量(以纳秒为单位),而 periodMS
是采样周期。
public static final double getCPUPerc(long cpuTimeDiffNS, long periodMS) {
if (periodMS == 0) return 0;
double cpuTimeDiffMS = cpuTimeDiffNS / 1000000d;
int procs = Runtime.getRuntime().availableProcessors();
long availableTime = periodMS * procs;
double perc = cpuTimeDiffMS / availableTime;
return perc * 100d;
}
以下是数据采集的一些示例:
0
87.5
133.8288232
160.8231707
197.7896341
209.6036585
248.822774
274.3902439
267.9115854
271.3414634
277.1067759
283.1554878
272.1036585
279.4000734
283.9176829
283.5365854
275.9146341
282.4578033
278.9634146
261.0536937
254.6071775
286.662182
278.9634146
276.7245597
288.4908537
281.6933708
286.9664634
279.7822896
276.2957317
280.4878049
275.5335366
271.7557485
280.8689024
287.2689689
281.6933708
267.5097276
273.2469512
286.1735835
289.6341463
296.875
279.4000734
289.2530488
282.8400196
288.4908537
287.4266145
288.1097561
286.5853659
288.9554795
238.1207192
288.4908537
288.7063531
290.3963415
286.662182
277.4390244
290.4843444
281.6310976
271.7557485
272.8658537
283.2222358
250.7621951
编辑:根据要求,输入收集功能(您可能可以忽略这一点):
// returns CPU time in NS for a thread group (recursively)
public static long getCPUTime(ThreadGroup tg) {
synchronized (TGLOCK) {
int size;
do {
size = tg.enumerate(tgThreads, true);
if (size <= tgThreads.length) continue;
tgThreads = new Thread[size];
} while (size > tgThreads.length);
long totalTime = 0;
for (int i = 0; i < size; i++) {
totalTime += getCPUTime(tgThreads[i]);
}
return totalTime;
}
}
public static long getCPUTime(Thread t) {
return threadMXBean.getThreadCpuTime(t.getId());
}
public static ThreadGroup getRootThreadGroup() {
// Find the root thread group
ThreadGroup root = Thread.currentThread().getThreadGroup().getParent();
while (root.getParent() != null) {
root = root.getParent();
}
return root;
}
以及输入(同样,您可能可以忽略这一点):
simCPUTimeNS = getCPUTime(kks.getSimThreadGroup());
appsCPUTimeNS = getCPUTime(kks.getAppThreadGroup());
lwjns3CPUTimeNS = getCPUTime(kks.getKKSThreadGroup());
simCoreCPUTimeNS = getCPUTime(kks.getSimThread());
totalCPUTimeNS = getCPUTime(getRootThreadGroup());
simCPUTimeNSDiff = simCPUTimeNS - lastSimCPUTimeNS;
appsCPUTimeNSDiff = appsCPUTimeNS - lastAppsCPUTimeNS;
lwjns3CPUTimeNSDiff = lwjns3CPUTimeNS - lastLwjns3CPUTimeNS;
simCoreCPUTimeNSDiff = simCoreCPUTimeNS - lastSimCoreCPUTimeNS;
totalCPUTimeNSDiff = totalCPUTimeNS - lastTotalCPUTimeNS;
lastSimCPUTimeNS = simCPUTimeNS;
lastAppsCPUTimeNS = appsCPUTimeNS;
lastLwjns3CPUTimeNS = lwjns3CPUTimeNS;
lastSimCoreCPUTimeNS = simCoreCPUTimeNS;
lastTotalCPUTimeNS = totalCPUTimeNS;
simCPUPerc = getCPUPerc(simCPUTimeNSDiff, currDiffMS);
appsCPUPerc = getCPUPerc(appsCPUTimeNSDiff, currDiffMS);
lwjns3CPUPerc = getCPUPerc(lwjns3CPUTimeNSDiff, currDiffMS);
simCoreCPUPerc = getCPUPerc(simCoreCPUTimeNSDiff, currDiffMS);
totalCPUPerc = getCPUPerc(totalCPUTimeNSDiff, currDiffMS);
为任何帮助干杯,我确信答案是明显;)
克里斯
I'm having issues with a Java algorithm I created to convert nanosecond CPU time usage (obtained via JMX) to a percentage out of 100%. The algorithm appears to be giving numbers greater than 100%, which I assume to be due to multiple available processors, although the code should sort this out. The algorithm can be seen below. cpuTimeDiffNS
is the amount of CPU time used in nanoseconds, while periodMS
is the sampled period.
public static final double getCPUPerc(long cpuTimeDiffNS, long periodMS) {
if (periodMS == 0) return 0;
double cpuTimeDiffMS = cpuTimeDiffNS / 1000000d;
int procs = Runtime.getRuntime().availableProcessors();
long availableTime = periodMS * procs;
double perc = cpuTimeDiffMS / availableTime;
return perc * 100d;
}
Here's some samples from the data acquisition:
0
87.5
133.8288232
160.8231707
197.7896341
209.6036585
248.822774
274.3902439
267.9115854
271.3414634
277.1067759
283.1554878
272.1036585
279.4000734
283.9176829
283.5365854
275.9146341
282.4578033
278.9634146
261.0536937
254.6071775
286.662182
278.9634146
276.7245597
288.4908537
281.6933708
286.9664634
279.7822896
276.2957317
280.4878049
275.5335366
271.7557485
280.8689024
287.2689689
281.6933708
267.5097276
273.2469512
286.1735835
289.6341463
296.875
279.4000734
289.2530488
282.8400196
288.4908537
287.4266145
288.1097561
286.5853659
288.9554795
238.1207192
288.4908537
288.7063531
290.3963415
286.662182
277.4390244
290.4843444
281.6310976
271.7557485
272.8658537
283.2222358
250.7621951
Edit: as requested, the input gathering functions (you can probably ignore this):
// returns CPU time in NS for a thread group (recursively)
public static long getCPUTime(ThreadGroup tg) {
synchronized (TGLOCK) {
int size;
do {
size = tg.enumerate(tgThreads, true);
if (size <= tgThreads.length) continue;
tgThreads = new Thread[size];
} while (size > tgThreads.length);
long totalTime = 0;
for (int i = 0; i < size; i++) {
totalTime += getCPUTime(tgThreads[i]);
}
return totalTime;
}
}
public static long getCPUTime(Thread t) {
return threadMXBean.getThreadCpuTime(t.getId());
}
public static ThreadGroup getRootThreadGroup() {
// Find the root thread group
ThreadGroup root = Thread.currentThread().getThreadGroup().getParent();
while (root.getParent() != null) {
root = root.getParent();
}
return root;
}
and the inputs (again, you can probably ignore this):
simCPUTimeNS = getCPUTime(kks.getSimThreadGroup());
appsCPUTimeNS = getCPUTime(kks.getAppThreadGroup());
lwjns3CPUTimeNS = getCPUTime(kks.getKKSThreadGroup());
simCoreCPUTimeNS = getCPUTime(kks.getSimThread());
totalCPUTimeNS = getCPUTime(getRootThreadGroup());
simCPUTimeNSDiff = simCPUTimeNS - lastSimCPUTimeNS;
appsCPUTimeNSDiff = appsCPUTimeNS - lastAppsCPUTimeNS;
lwjns3CPUTimeNSDiff = lwjns3CPUTimeNS - lastLwjns3CPUTimeNS;
simCoreCPUTimeNSDiff = simCoreCPUTimeNS - lastSimCoreCPUTimeNS;
totalCPUTimeNSDiff = totalCPUTimeNS - lastTotalCPUTimeNS;
lastSimCPUTimeNS = simCPUTimeNS;
lastAppsCPUTimeNS = appsCPUTimeNS;
lastLwjns3CPUTimeNS = lwjns3CPUTimeNS;
lastSimCoreCPUTimeNS = simCoreCPUTimeNS;
lastTotalCPUTimeNS = totalCPUTimeNS;
simCPUPerc = getCPUPerc(simCPUTimeNSDiff, currDiffMS);
appsCPUPerc = getCPUPerc(appsCPUTimeNSDiff, currDiffMS);
lwjns3CPUPerc = getCPUPerc(lwjns3CPUTimeNSDiff, currDiffMS);
simCoreCPUPerc = getCPUPerc(simCoreCPUTimeNSDiff, currDiffMS);
totalCPUPerc = getCPUPerc(totalCPUTimeNSDiff, currDiffMS);
Cheers for any help, I'm sure the answer is obvious ;)
Chris
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
因此,我们使用类似的代码来计算平均负载,(事实证明)它有一个错误,也可能存在于您的代码中。我们使用 getAllThreadIds() 但它只返回“活动”线程,并且 enumerate 也会执行此操作。如果任何线程停止,那么总 CPU 时间可能会减少。我不明白这会如何导致这些值超过 100%。
关于您的代码的一些评论:
synchronized (TGLOCK)
行?这是为了同步ThreadGroup
对象吗?if (size <= tgThreads.length) continue;
应该是break;
。没有必要双重测试。enumerate
返回放入数组中的线程数。这总是<= tg.length
因此,如果我准备得正确,数组将永远不会增长。如果它确实返回了更大的大小,那么您将得到 NPE,因为您在 while 检查之前有tgThreads = new Thread[size];
,而这永远不会是真的。希望这至少有所帮助。
So we use similar code to calculate the load average and (as it turns out) it has a bug that may also be in your code. We use
getAllThreadIds()
but it only returns the "active" threads andenumerate
does this also. If any of your threads stop then the total cpu time may go down. I don't see how this would cause the the values to go above 100%.Couple comments about your code:
synchronized (TGLOCK)
line? Is this to synchronize theThreadGroup
object?if (size <= tgThreads.length) continue;
should be abreak;
. There's no need to double test.enumerate
returns the number of threads put in the array. This is always going to be<= tg.length
so the array will never grow if I'm readying it right. If it did return a larger size then you'd be getting NPEs since you havetgThreads = new Thread[size];
right before the while check which will never be true.ThreadGroup
at all? We are using the following which doesn't need to recurse or anything:Hope this helps at least somewhat.
我正在时间膨胀的 JVM 上运行(速度慢了 5 倍),看起来我忘记在 os_windows.cpp 中的 C++ JVM 代码的一部分中进行膨胀(
os::thread_cpu_time
)进行调整时。哎呀。它使用 Windows 时间函数timeGetTime()
。这样就可以解释了。I'm running on a time-dilated JVM (5x slowdown), and it looks like I forgot to dilate in one part of the C++ JVM code in
os_windows.cpp
(os::thread_cpu_time
) when making adjustments. Oops. It usestimeGetTime()
, a Windows time function. That'd explain it.