-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
bpo-36670: regrtest WindowsLoadTracker computes LOAD_FACTOR_1 #16556
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, and values seem consistent from some quick testing!
I compared the value computed load average to the moving average over the last minute: statistics.mean(values) where values are the 60 latest processor_queue_length. The load average moves way more slowly and than the moving average. But it's part of the design of the load average, and Linux load average behaves the same. My main worry is that Python load average always starts at 0.0 and so it takes at least one minute to reach the average. I modified the code to initialize the load to the first processor_queue_length. This is not perfect, but it helps to get an idea of the real load average in the first 60 seconds. After one minute, the value using the old and the new code should converge anyway. -- I took this PR as an opportunity to push other enhancements and bugfixes. |
Example from the Win64 job of Azure Pipelines:
Comparison with PR #16555:
|
* Add log() method: add timestamp and load average prefixes to main messages. * WindowsLoadTracker: * LOAD_FACTOR_1 is now computed using SAMPLING_INTERVAL * Initialize the load to the arithmetic mean of the first 5 values of the Processor Queue Length value (so over 5 seconds), rather than 0.0. * Handle BrokenPipeError and when typeperf exit. * format_duration(1.5) now returns '1.5 sec', rather than '1 sec 500 ms'
I made more tests and using a single value is really too raw. I modified my PR to use the arithmetic mean on the first 5 values instead. It helps to converge faster to the "real" load average. Example of debug traces:
The load average is initialized to 4.4 and it moves to 5.36 after 1 minute: 4.4 is a better estimation than 0.0 for the first value ;-)
|
(Comment on my PR #16555) @ammaraskar: "If you feel like 1 second is better, then the new constant would be 0.98347145382161748947374 https://www.wolframalpha.com/input/?i=1%2Fexp%281%2F60%29 " Linux updates the load average every 5 seconds. But it's computed in the kernel. The problem here is that we start "from zero". I chose to compute the load average every second to converge faster to the "real" load average. The value of 1 second also helps my current implementation to compute the initial value. Getting samples every second and use the 5 first values to initial the load means that we can only seen the first load value after 5 seconds. Getting samples every 5 seconds would mean that using my current implementation, we could only see the first load value after 25 seconds. Or we could continue to initialize the load to 0.0, but it would mean that the first values before the first minute would be less accurate. |
New logs with my latest PR, from Azure Pipelines. The load was initialized to 8.37, whereas it reached 4.96 after 1 minute. It seems like the first value was a little bit "far" from the "real" load.
|
My previous comment was for Win64. Logs from Win32 job: First value of 3.40 => 3.20 after 1 minute.
|
…H-16550) (GH-16560) * bpo-36670, regrtest: Fix WindowsLoadTracker() for partial line (GH-16550) WindowsLoadTracker.read_output() now uses a short buffer for incomplete line. (cherry picked from commit 3e04cd2) * bpo-36670: Enhance regrtest WindowsLoadTracker (GH-16553) The last line is now passed to the parser even if it does not end with a newline, but only if it's a valid value. (cherry picked from commit c65119d) * bpo-36670: Enhance regrtest (GH-16556) * Add log() method: add timestamp and load average prefixes to main messages. * WindowsLoadTracker: * LOAD_FACTOR_1 is now computed using SAMPLING_INTERVAL * Initialize the load to the arithmetic mean of the first 5 values of the Processor Queue Length value (so over 5 seconds), rather than 0.0. * Handle BrokenPipeError and when typeperf exit. * format_duration(1.5) now returns '1.5 sec', rather than '1 sec 500 ms' (cherry picked from commit 098e256)
…ythonGH-16550) (pythonGH-16560) * bpo-36670, regrtest: Fix WindowsLoadTracker() for partial line (pythonGH-16550) WindowsLoadTracker.read_output() now uses a short buffer for incomplete line. (cherry picked from commit 3e04cd2) * bpo-36670: Enhance regrtest WindowsLoadTracker (pythonGH-16553) The last line is now passed to the parser even if it does not end with a newline, but only if it's a valid value. (cherry picked from commit c65119d) * bpo-36670: Enhance regrtest (pythonGH-16556) * Add log() method: add timestamp and load average prefixes to main messages. * WindowsLoadTracker: * LOAD_FACTOR_1 is now computed using SAMPLING_INTERVAL * Initialize the load to the arithmetic mean of the first 5 values of the Processor Queue Length value (so over 5 seconds), rather than 0.0. * Handle BrokenPipeError and when typeperf exit. * format_duration(1.5) now returns '1.5 sec', rather than '1 sec 500 ms' (cherry picked from commit 098e256) (cherry picked from commit de3195c) Co-authored-by: Victor Stinner <vstinner@python.org>
…H-16550) (GH-16560) * bpo-36670, regrtest: Fix WindowsLoadTracker() for partial line (GH-16550) WindowsLoadTracker.read_output() now uses a short buffer for incomplete line. (cherry picked from commit 3e04cd2) * bpo-36670: Enhance regrtest WindowsLoadTracker (GH-16553) The last line is now passed to the parser even if it does not end with a newline, but only if it's a valid value. (cherry picked from commit c65119d) * bpo-36670: Enhance regrtest (GH-16556) * Add log() method: add timestamp and load average prefixes to main messages. * WindowsLoadTracker: * LOAD_FACTOR_1 is now computed using SAMPLING_INTERVAL * Initialize the load to the arithmetic mean of the first 5 values of the Processor Queue Length value (so over 5 seconds), rather than 0.0. * Handle BrokenPipeError and when typeperf exit. * format_duration(1.5) now returns '1.5 sec', rather than '1 sec 500 ms' (cherry picked from commit 098e256) (cherry picked from commit de3195c) Co-authored-by: Victor Stinner <vstinner@python.org>
* Add log() method: add timestamp and load average prefixes to main messages. * WindowsLoadTracker: * LOAD_FACTOR_1 is now computed using SAMPLING_INTERVAL * Initialize the load to the arithmetic mean of the first 5 values of the Processor Queue Length value (so over 5 seconds), rather than 0.0. * Handle BrokenPipeError and when typeperf exit. * format_duration(1.5) now returns '1.5 sec', rather than '1 sec 500 ms'
https://bugs.python.org/issue36670