-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[Backport 5.2] Reload reclaimed bloom filters when memory is available #18624
Conversation
Renamed local variable in sstable::total_reclaimable_memory_size in preparation for the next patch which adds a new member variable _total_memory_reclaimed to the sstable class. Signed-off-by: Lakshmi Narayanan Sreethar <lakshmi.sreethar@scylladb.com> (cherry picked from commit a53af1f)
Added a member variable _total_memory_reclaimed to the sstable class that tracks the total memory reclaimed from a sstable. Signed-off-by: Lakshmi Narayanan Sreethar <lakshmi.sreethar@scylladb.com> (cherry picked from commit 02d272f)
Renamed the intrusive list link type to differentiate it from the set link type that will be added in an upcoming patch. Signed-off-by: Lakshmi Narayanan Sreethar <lakshmi.sreethar@scylladb.com> (cherry picked from commit 3ef2f79)
Signed-off-by: Lakshmi Narayanan Sreethar <lakshmi.sreethar@scylladb.com> (cherry picked from commit 140d887) # Conflicts: # sstables/sstables.hh
The new set holds the sstables from where the memory has been reclaimed and is sorted in ascending order of the total memory reclaimed. Signed-off-by: Lakshmi Narayanan Sreethar <lakshmi.sreethar@scylladb.com> (cherry picked from commit 2340ab6)
Added support to reload components from which memory was previously reclaimed as the total memory of reclaimable components crossed a threshold. The implementation is kept simple as only the bloom filters are considered reclaimable for now. Signed-off-by: Lakshmi Narayanan Sreethar <lakshmi.sreethar@scylladb.com> (cherry picked from commit 54bb03c)
Signed-off-by: Lakshmi Narayanan Sreethar <lakshmi.sreethar@scylladb.com> (cherry picked from commit 69b2a12) # Conflicts: # test/boost/sstable_datafile_test.cc
…e_scan_incomplete_sstables The testcase uses an sstable whose mutation key and the generation are owned by different shards. Due to this, when process_sstable_dir is called, the sstable gets loaded into a different shard than the one that was intended. This also means that the sstable and the sstable manager end up in different shards. The following patch will introduce a condition variable in sstables manager which will be signalled from the sstables. If the sstable and the sstable manager are in different shards, the signalling will cause the testcase to fail in debug mode with this error : "Promise task was set on shard x but made ready on shard y". So, fix it by supplying appropriate generation number owned by the same shard which owns the mutation key as well. Signed-off-by: Lakshmi Narayanan Sreethar <lakshmi.sreethar@scylladb.com> (cherry picked from commit 2406406) # Conflicts: # test/boost/sstable_directory_test.cc
Start a fiber that gets notified whenever an sstable gets deleted. The fiber doesn't do anything yet but the following patch will add support to reload reclaimed components if there is sufficient memory. Signed-off-by: Lakshmi Narayanan Sreethar <lakshmi.sreethar@scylladb.com> (cherry picked from commit f758d7b)
…is available When an SSTable is dropped, the associated bloom filter gets discarded from memory, bringing down the total memory consumption of bloom filters. Any bloom filter that was previously reclaimed from memory due to the total usage crossing the threshold, can now be reloaded back into memory if the total usage can still stay below the threshold. Added support to reload such reclaimed filters back into memory when memory becomes available. Signed-off-by: Lakshmi Narayanan Sreethar <lakshmi.sreethar@scylladb.com> (cherry picked from commit 0b06119)
…mponents Signed-off-by: Lakshmi Narayanan Sreethar <lakshmi.sreethar@scylladb.com> (cherry picked from commit a080daa) # Conflicts: # test/boost/sstable_datafile_test.cc
Signed-off-by: Lakshmi Narayanan Sreethar <lakshmi.sreethar@scylladb.com> (cherry picked from commit 4d22c4b) # Conflicts: # sstables/sstables.cc # utils/error_injection.hh
Cherry-pick of 140d887 has failed:
Cherry-pick of 69b2a12 has failed:
Cherry-pick of 2406406 has failed:
Cherry-pick of a080daa has failed:
Cherry-pick of 4d22c4b has failed:
To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally |
Replaced by #18666 |
PR #17771 introduced a threshold for the total memory used by all bloom filters across SSTables. When the total usage surpasses the threshold, the largest bloom filter will be removed from memory, bringing the total usage back under the threshold. This PR adds support for reloading such reclaimed bloom filters back into memory when memory becomes available (i.e., within the 10% of available memory earmarked for the reclaimable components).
The SSTables manager now maintains a list of all SSTables whose bloom filter was removed from memory and attempts to reload them when an SSTable, whose bloom filter is still in memory, gets deleted. The manager reloads from the smallest to the largest bloom filter to maximize the number of filters being reloaded into memory.
(cherry picked from commit a53af1f)
(cherry picked from commit 02d272f)
(cherry picked from commit 3ef2f79)
(cherry picked from commit 140d887)
(cherry picked from commit 2340ab6)
(cherry picked from commit 54bb03c)
(cherry picked from commit 69b2a12)
(cherry picked from commit 2406406)
(cherry picked from commit f758d7b)
(cherry picked from commit 0b06119)
(cherry picked from commit a080daa)
(cherry picked from commit 4d22c4b)
Refs #18186