-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
DelegatingLogger seems to be a memory hog #1122
Comments
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
This might be worth fixing |
/lifecycle frozen |
Reading the code a bit, I think we're expecting the caller to call SetLogger with NullLogger{} if they actually want a null logger. Seems the delegating logger's only purpose is to keep log lines around until SetLogger is called, which might never be called if someone never sets it. I'm not sure if this is an actual problem or not, but I'm in favor of completely removing the |
We have a controllermanager that doesn't use the built-in logging, which means the logger construction in c-r falls back to the default in
pkg/log/log.go
which isNewDelegatingLogger(NullLogger{})
.Analyzing the memory usage of this controller I noticed that logging seems to have the second highest number of heap allocations:
IMHO we should be a lot more efficient in doing nothing.
/kind bug
The text was updated successfully, but these errors were encountered: