process.cpuUsage accuracy #8728

Activity

1. mscdex

   added

   processIssues and PRs related to the process subsystem.Issues and PRs related to the process subsystem.

   on Sep 23, 2016
2. tniessen

   added

   questionIssues asking questions about Node.js.Issues asking questions about Node.js.

   on Jun 2, 2017
3. Trott commented on Aug 7, 2017

   

   Trott

   on Aug 7, 2017

   Member

   More actions

   /ping @pmuellr
4. pmuellr commented on Aug 8, 2017

   

   pmuellr

   on Aug 8, 2017

   Last edited by pmuellr

   More actions

   Hi Nick, did you have any luck finding a good recipe? I tried your test1.js and test2.js, and got the following results:

   $ node test1.js
   elapsed time ms:   1504.27047
   elapsed user ms:   NaN
   elapsed system ms: NaN
   cpu percent:       NaN
   elapsed time ms:   3015.270453
   elapsed user ms:   NaN
   elapsed system ms: NaN
   cpu percent:       NaN
   ^C
   
   $ node test2.js
   elapsed time ms:   1503.639829
   elapsed user ms:   501.57
   elapsed system ms: 16.713
   cpu percent:       34.5%
   
   elapsed time ms:   1520.0664040000001
   elapsed user ms:   508.175
   elapsed system ms: 18.608
   cpu percent:       34.7%
   ^C
   

   test1.js seems to be treating the cpuUsage() values like hrtime() structures, which they aren't, hence the NaNs. test2.js seems to be calculating a reasonable results, for the first round, but I would have expected the second and subsequent ones to have an elapsed time of 1000ms (not 1500ms) - it seems like setInterval() schedules the next timer to go off AFTER the current one has finished, rather than a fixed "every XXX ms"? That's interesting, didn't realize it did that! (or forgotten it)

   seems to not account for number of cpu cores

   Correct, it does not account for cores, as far as I know. The underlying API measures the amount of CPU used across all cores, so if your program uses 100% CPU in the main JavaScript thread, but also does work in other threads, you should expect the resultant % value to be > 100%.

   I think CPU usage values like this are typically based on a single CPU; that's what I seem to see in Mac's Activity Monitor, for instance. Same sort of thing, where a process using most of two cores will show CPU % values like 200%.

   If you want to have a value of % of total machine CPUs used, you could of course divide by the number of CPUs.

   the tests for this feature have the wrong precision

   I believe you are right, and we should fix this.

   Seems like the following bits:

   const MICROSECONDS_PER_SECOND = 1000 * 1000;
   ...
   assert(diff.user <= SLOP_FACTOR * RUN_FOR_MS * MICROSECONDS_PER_SECOND);
   

   should be changed to:

   const MICROSECONDS_PER_MILLISECOND = 1000
   ...
   assert(diff.user <= SLOP_FACTOR * RUN_FOR_MS * MICROSECONDS_PER_MILLISECOND);
   
5. nickstanish commented on Aug 9, 2017

   

   nickstanish

   on Aug 9, 2017

   ContributorAuthor

   More actions

   Thanks for taking a look. After trying some more, I created a new example similar to test2 that is having results much more similar to what you would see in activity monitor.
   The trick here was to keep the elapsed time as close as possible to the refresh rate in activity monitor (based on a 2 second update frequency).

   I think that resolves any questions I had around process.cpuUsage, but we should still update the test to use the correct multiplier.
6. pmuellr commented on Aug 9, 2017

   

   pmuellr

   on Aug 9, 2017

   More actions

   Great!

   Agree that we should fix the test; would you like the "honors"? Otherwise I'll try to get around to it this week or next ...
7. nickstanish commented on Aug 9, 2017

   

   nickstanish

   on Aug 9, 2017

   ContributorAuthor

   More actions

   Yeah, here it is: #14706
8. Trott

   added a commit that references this issue on Aug 10, 2017

   test: fix conversion of microseconds in test

   ...

   a439cf4
9. Trott

   closed this as completedin a439cf4on Aug 10, 2017
10. addaleax

    added a commit that references this issue on Aug 10, 2017

    test: fix conversion of microseconds in test

    ...

    06ba2da