Fix Total CPU % on /workers tab to normalize by total nthreads#9195
Fix Total CPU % on /workers tab to normalize by total nthreads#9195ernestprovo23 wants to merge 2 commits intodask:mainfrom
Conversation
The WorkerTable's Total CPU % divided by len(workers) instead of sum(nthreads), producing incorrect values when workers have multiple threads (e.g., 400% instead of 50%). This aligns the "cpu" column with the already-correct "cpu_fraction" column, matching the same fix pattern as PR dask#3897 for memory_percent. Closes dask#8490
|
All tests pass across Python 3.10–3.14 on Ubuntu and macOS, and the The Happy to add additional test coverage if needed — just let me know. |
Unit Test ResultsSee test report for an extended history of previous test failures. This is useful for diagnosing flaky tests. 31 files ±0 31 suites ±0 11h 5m 53s ⏱️ - 4m 19s For more details on these failures, see this check. Results for commit 7975318. ± Comparison against base commit 4fb4814. ♻️ This comment has been updated with latest results. |
There was a problem hiding this comment.
I find it deeply confusing to have cpu go up to 100% on the total and to 400% on the individual workers. On the other hand, as #8490 (comment) points out, changing the individual workers' reading from 0%~400% to 0%~100% would cause more confusion and make the board less useful.
I think I would be inclined to merge if it was shown as a pure number showing the total number of cores used.
So for a 20-workers cluster with 4 CPUs each,
- each worker would continue ranging between 0% and 400% (as it is something users are used to see on any PC),
- while the total would go from 0 to 80 (instead of 8000% like in the comment #8490 (comment)).
Per review feedback: the Total row now displays a raw core count (e.g. 3.5 = 3.5 cores busy) while per-worker rows keep showing the familiar 0-400% style. Uses HTMLTemplateFormatter with a hidden _is_total column for conditional rendering in the same Bokeh DataTable column.
|
thanks @crusaderky, updated based on your feedback. total row now shows raw core count (e.g. 3.5 = 3.5 cores busy) instead of a percentage. per-worker rows still show the 0-400% style, unchanged. used an |
2 participants
Closes #8490
The WorkerTable's Total CPU % calculation divided by
len(workers)instead ofsum(nthreads), producing incorrect values when workers have multiple threads (e.g., a 2-worker cluster with 8 threads each, one maxed out, showed 400% instead of 50%).This one-line fix aligns the
cpucolumn with the already-correctcpu_fractioncolumn by usingsum(ws.nthreads)as the divisor. Same fix pattern as PR #3897, which corrected the identical bug formemory_percent.pre-commit run --all-files