-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: add num cpu cores to process.report output #307
Comments
Seems pretty reasonable to me, @richardlau, thoughts? |
Yes, sounds reasonable. One question is whether it would be useful to include more information about the CPU's in the report, e.g. the information returned by The report is written out in C++ code -- for the |
@richardlau Isn't the cpu time information in the At any rate, I don't have a use for anything past the number of cores, and could only speculate on what someone would want to do with the extra info here. |
The only reason I'm speculating on whether it's worth including the extra information is in terms of the report format (i.e. we could go the simple route and have |
+1 on adding the number of cores to the report. |
The report shows CPU consumption %, but without the number of CPU cores, a consumer cannot tell if the percent (given across all cores) is actually problematic. E.g., 100% on one CPU is a problem, but 100% on four CPUs is not necessarily. This change adds CPU information (similar to `os.cpus()`) to the report output. Extra info besides the count is also provided as to avoid future breaking changes in the eventuality that someone needs it; changing the datatype of `header.cpus` would be breaking. PR-URL: nodejs#28188 Refs: nodejs/diagnostics#307
The report shows CPU consumption %, but without the number of CPU cores, a consumer cannot tell if the percent (given across all cores) is actually problematic. E.g., 100% on one CPU is a problem, but 100% on four CPUs is not necessarily. This change adds CPU information (similar to `os.cpus()`) to the report output. Extra info besides the count is also provided as to avoid future breaking changes in the eventuality that someone needs it; changing the datatype of `header.cpus` would be breaking. PR-URL: nodejs#28188 Refs: nodejs/diagnostics#307 Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
The report shows CPU consumption %, but without the number of CPU cores, a consumer cannot tell if the percent (given across all cores) is actually problematic. E.g., 100% on one CPU is a problem, but 100% on four CPUs is not necessarily. This change adds CPU information (similar to `os.cpus()`) to the report output. Extra info besides the count is also provided as to avoid future breaking changes in the eventuality that someone needs it; changing the datatype of `header.cpus` would be breaking. PR-URL: #28188 Refs: nodejs/diagnostics#307 Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
The report shows CPU consumption %, but without the number of CPU cores, a consumer cannot tell if the percent (given across all cores) is actually problematic. E.g., 100% on one CPU is a problem, but 100% on four CPUs is not necessarily. This change adds CPU information (similar to `os.cpus()`) to the report output. Extra info besides the count is also provided as to avoid future breaking changes in the eventuality that someone needs it; changing the datatype of `header.cpus` would be breaking. PR-URL: #28188 Refs: nodejs/diagnostics#307 Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
@boneskull nodejs/node#28188 landed, so the number of CPUs can be determined by the number of entries in |
yep! |
In the report generated by
process.report
, we haveresourceUsage.cpuConsumptionPercent
.As per the original PR, this is the percentage of CPU in use across all cpu cores. The issue I'm raising here didn't seem to be considered--rather the maintainer decided that granular information about each core was not useful (and they are right).
Now, it's been awhile since my computer architecture classes, but what I think this means is that you cannot just look at the number reported and know what it means. A usage of 100% on system A may be a problem, but a usage of 120% on system B might not be.
(We are not guaranteed to be consuming the report on the machine it was generated on, either.)
So, I propose adding
header.osCpus
, which would be a number corresponding to the output ofos.cpus().length
. A consumer can then use both of these to determine the theoretical ceiling of the CPU consumption percentage value (multiplyheader.osCpus
by 100).If it's a good idea, I could implement. If I can do it in
lib/internal/process/report.js
that'd be even better. 😝The text was updated successfully, but these errors were encountered: