Tags: dragonflydb/dragonfly
Tags
chore: implement the iterative fragmentation check Before - we had relatively slow check for counting wasted fragmentation via zmalloc_get_allocator_wasted_blocks that took 10ms or more in production. The reason for that is that it iterate over all the memory pages on a single shard through the single call. Now we implement an iterative version of it by iterating over a single page queue data-structure in the heap. Once we start the iterative process we will continue aggregating stats over all the page queues in the heap until we reach the end and then conclude if defragmentation is needed. this should reduce the call time to EngineShard::DefragTaskState::CheckRequired by x70 (number of page queues in the heap). Signed-off-by: Roman Gershman <roman@dragonflydb.io>
server: Empty out stored commands vector and backing memory The vector if cleared does not reduce its capacity. Swapping with an empty vector both destroys the stored commands and prevents holding back capacity. With simply clearing the vector, servers with high number of client connections ends up using a lot of memory even when these vectors (which are created for multi/exec) are empty. Signed-off-by: Abhijat Malviya <abhijat@dragonflydb.io>
PreviousNext