-
-
Notifications
You must be signed in to change notification settings - Fork 964
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
fix: avoid excessive memory allocations #2389
Conversation
49cf236
to
c55e16d
Compare
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.
Awesome, thank you for your contribution! This looks pretty good and I have some ideas how to improve it further :)
cache, err := ristretto.NewCache(&ristretto.Config{ | ||
NumCounters: 10 * 10000, | ||
MaxCost: 60 * 10000, // BCrypt hash size is 60 bytes | ||
BufferItems: 64, |
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.
The cost in ristretto is set is kinda weird. For example, it is probably required to ignore the internal cost and use a custom cost function:
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.
Alright. I've added ignoreInternalCost=true
but I'm not sure if custom cost function is needed at this point.
c55e16d
to
a012ef2
Compare
Codecov Report
@@ Coverage Diff @@
## master #2389 +/- ##
==========================================
- Coverage 76.60% 76.56% -0.04%
==========================================
Files 315 315
Lines 17328 17326 -2
==========================================
- Hits 13274 13266 -8
- Misses 3120 3124 +4
- Partials 934 936 +2
Continue to review full report at Codecov.
|
This PR changes internal storage for HIBP API call results to use ristretto cache instead of plain map to avoid excessive memory allocations when handling substantial load (each checked hash is stored indefinitely in memory).
Related issue(s)
Checklist
introduces a new feature.
contributing code guidelines.
vulnerability. If this pull request addresses a security. vulnerability, I
confirm that I got green light (please contact
[email protected]) from the maintainers to push
the changes.
works.
Further Comments
This patch was running for a few days on our cluster and it looks like memory usage is not increasing and stabilised around 70MB which is great :-)