getProcessCpuLoadBetweenTicks vs getSystemCpuLoadBetweenTicks?

[ope-nz]

I have an application that is monitoring overall CPU and process CPU using OSHI 5.x

Today I noticed one server reported a 43% overall CPU usage however when I checked the total of the process CPU usage it was 21% - values are stored rounded.

This Azure server show as 2 physical and 4 logical cores.

According to the docs and the demo GUI the process CPU usage "should be divided by the number of logical processors".

Is this still correct? If I divided by physical cores I would get 42 which aligns with the overall CPU usage - Im not sure if this is just a coincidence.

Or is the problem with the overall CPU?

[dbwiddis]

This is a good question and probably deserves a FAQ entry. :)

I'm not sure of the time interval you're using, but I'll try to outline the calculations clearly here which will hopefully answer your question.

Key point: the "divide by logical processors" applies only to the process CPU usage as displayed on the Windows Task Manager, which (by default) scales usage so that any one process would max out at 100% usage. It's possible to change that default setting.

The OSHI "usage" calculations are mostly convenience functions to do math that you could do yourself with the raw tick values. Looking at their implementations (in AbstractOSProcess and AbstractCentralProcessor) may be enlightening.

For overall System and per-Processor ticks, no correction is needed, as "Idle Time" is saved for the system total and for each processor. So in these cases the usage calculation is (total - idle) / total. If you have four logical processors it's possible to accumulate either 4 user+system ticks or 4 "idle" ticks per 1 clock tick, so no scaling is needed.

For individual processes, however, there is no "idle" time stored, just user+system ticks. The usage calculation is total / uptime. But that uptime is, in theory, applicable to each logical processor. A multithreaded process fully utilizing 4 processors will accumulate 4 user+system ticks for a single clock tick, and report 400% usage. This matches the reporting on Unix-based systems (including Linux and macOS) and it's possible to configure Windows Task Manager to display it this way as well. However, by default, Windows will scale down process ticks so that the max any individual process can consume is 100%.

For example, I just wrote a simple single-threaded endless loop in Java, and ran it. It displayed 25% usage in my Windows task manager, on a 4-core system. On macOS, the identical program shows 100% usage.

All that said, addressing your individual situation:

• In theory if you added up the usage of individual processes, you would have to divide by the number of logical processors to match the Windows Task manager display.
• Realize that the clock tick granularity on Windows is 1/64 of a second, about 16.25 milliseconds. That's a lot of potential rounding error if you're adding up a bunch of individual processes over a short timespan. In fact, I'd not recommend adding up individual processes anyway, just use the existing CentralProcessor methods which already take this into account.

[dbwiddis]

Updated the FAQ in 5448cb6