mv-tuning4 #117
mv-tuning4 #117
Conversation
…_set.cc limits accordingly
…gic to again exempt AAE
…e level-1 penalty much lighter.
…l-1 now linear penalty
…ooming. faster it purges the less rewrite of same old data. write amplification drops by one with these changes on large ingest test.
| {10485760, 524288000, 57671680, 41943040000ULL, 33554432000ULL, 524288000, false}, | ||
| {10485760, 629145600, 57671680, 419430400000ULL, 335544320000ULL, 629145600, false}, | ||
| {10485760, 734003200, 57671680, 4194304000000ULL, 3355443200000ULL, 734003200, false} | ||
| {10485760, 262144000, 57671680, 209715200, 0, 420000000, true}, |
There was a problem hiding this comment.
Looks like "300000000" changed to "420000000" and some formatting updated the whole chunk of text. Did I miss anything? Why that change?
There was a problem hiding this comment.
For once, I actually documented a change … see line 49 of comments above. If still unclear, I will elaborate.
There was a problem hiding this comment.
Here's the comment:
// level-0 file size of 420,000,000 applies to output files of this level
// being written to level-1. The value is 7 times the default maximum
// write buffer size of 60,000,000. Why seven times: 6 level-0 files typically compact
// to one level-1 file and are each slightly larger than 60,000,000.
Which makes perfect sense, I thought it was another use of the magic "42" number rather than a real calculation. Guess I was wrong!
|
I've not built/run this code but by visual inspection it looks like improvements to heuristics in parts of LevelDB that make sense to me from a casual inspection. |
|
Thank you for the review. |
|
Without actually running the code (due to time constraints) I'm going to say I'm +1, but I'll suggest strongly that you should solicit at least one engineer to agree before merging it. |
Description here: https://github.com/basho/leveldb/wiki/mv-tuning4