Fix DB.Close performance regression in large databases #434 #2064
Conversation
This file contains hidden or 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
…zer calls, addressing the performance regression in for large databases (2.5TB).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
What changed?
Optimized
cache.(*Cache).Closeby removing duplicate callback calls inenumerateNodesWithCBand batching finalizer calls, addressing the performance regression inDB.Closefor large databases (2.5TB).Why?
Fixes Issue #434, where
DB.Closetook several minutes after upgrading to commit126854af5e6d. The issue was caused by inefficient cache node enumeration, exacerbated by large cache sizes.How did you test it?
TestDB_CloseLargeDBto simulate a large database and verifyDB.Closeperformance.BenchmarkDB_Closeto measure close time.go test -race ./...to ensure no regressions or data races.