-
Notifications
You must be signed in to change notification settings - Fork 5
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
handler: avoid repetitive bitmap writebacks on evict (#53)
* handler: avoid repetitive bitmap writebacks on evict This commit changes the behavior of the database handler which manages the state of on-disk allocation bitmaps. The old behavior relied on keeping a single root node in cache to avoid consequent writebacks of updates inbetween sync's. An evicted root node with the current inter-sync data attached (e.g. bitmaps and size tracking info from the last root node writeback at the very end of the last sync which is written back to the superblock) would be in the "modified" state and therefore requiring a writeback when new entries should be added, this does two things it moves the node to the "in writeback" state, and it triggers a new allocation in the writeback sequence, which moves the node to the "modified" state and erases the writeback validity and thus restarting the cycle again. This resulted in tanking of performance on read-heavy queries, some preliminary results from testing on my machine shows 2x in some benchmarks and much better scaling behavior after this patch. The main problems for the slowdown seemed to be the repetitive cache eviction calls, which lock down the cache for all reading threads, and the additional load on storage device leading to some degradation especially in read-only scenarios. This commit changes the behavior, instead of committing all changes directly to the root tree on updates it buffers these changes together with their allocators in the handler itself. Their is still the same guarantee of disk consistency, as we only guarantee persistency on successful sync's, but all changes are just dumped into the root tree on the invocation of sync. Furthermore, this requires us to cache the changes in a format which allows further allocations without overwriting the old ones, for this purpose a small cache is added directly in the handler to accomodate the changed bitmaps. This cache is emptied on sync's to accurately free cow-afflicted regions after sync calls. This cache is unbound at the moment, but it requires 32 MiB for 1 TiB of *active* data without any sync's inbetween. Which I would assume as unlikely. * handler: fix reused allocation of previous root node allocation Erasing the old root ptr lock lead to reallocation of root node pages which eliminates consistency. This commit simply updates this entry to the new value.
- Loading branch information
jwuensche
authored
Mar 7, 2024
1 parent
c03dbf8
commit f49de67
Showing
5 changed files
with
73 additions
and
42 deletions.
There are no files selected for viewing
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
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
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
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
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