Reduce log noise from next run being in past #15670
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Yes to calling time once and passing it around. Makes unit/functional testing involving time sane too. |
AlanCoding
force-pushed
the
forget_the_past
branch
from
9696d49 to
a8b9fdb
Compare
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
SUMMARY
We have a very low-value log about the next run of something being in the past.
I believe this should (in theory) address this issue. I will see about verifying this with SOS reports. I know this comes up a lot, and I believe it's because "control" tasks can take a non-trivial amount of time. And that is a big issue, which we probably want to add some other logging for, in a more specific and actionable form.
EDIT:
Specifically, I'd like to generalize the
log_excess_runtimedecorator and use it on the cleanup task.That action is done in #15675, so if this behavior is observed in the future, we will not get logs about schedule misses, but will instead get logs that say "method xyz too 2.3 seconds, which is bad", assuming we merge both patches. That is the format of feedback we want.
ISSUE TYPE
COMPONENT NAME