getProcessCPULoad returns different CPU percentage as comparead to top linux command

David Holmes david.holmes at oracle.com
Mon Nov 6 06:36:19 UTC 2023


On 6/11/2023 3:53 pm, Nikhil Agarwal wrote:
> Hi David,
> 		Thanks for your reply , It seems top command  also uses /proc/stat to do the magic .Reading a similar issue for top vs another monitor tool on
> https://medium.com/@yogita088/how-to-calculate-cpu-usage-proc-stat-vs-top-e74f99f02d08  , What is the duration for which getProcessCPUload reports CPU utilisation , is it from system start time or 1 sec or x seconds ? It is configurable in top command as -d parameter. This might help to discover difference btw top vs getprocesscpuload

For getProcessCpuLoad it is the time since the JVM process initialized 
the performance counters. At VM init the counters are read from 
/proc/stat and /proc/self/stat and stashed away. Then when you ask for 
the load the counters are read again and the initial values subtracted 
to give the load across the lifetime of the process. You can see the 
code here:

https://github.com/openjdk/jdk/blob/master/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c

David

> regards
> Nikhil
> 
> 
> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: 06 November 2023 10:58
> To: Nikhil Agarwal <nikhil.a.agarwal at oracle.com>; serviceability-dev at openjdk.org
> Subject: Re: getProcessCPULoad returns different CPU percentage as comparead to top linux command
> 
> Hi,
> 
> On 3/11/2023 11:50 pm, Nikhil Agarwal wrote:
>> Hi All,
>>
>>                 getProcessCPULoad returns different CPU percentage as
>> compared to top linux command intermittently . Does it supposed to
>> returned same data as top command always .  Should the
>> getProcessCPULoad value be same as  top/number of cpus always ?
> 
> I've no idea how top calculates what it does. The VM reads the first line of /proc/stat to get the various tick counters.
> 
> HTH.
> 
> David
> 
>> regards
>>
>> Nikhil
>>


More information about the serviceability-dev mailing list