Reset later item flag after defrag later is done#12694
Reset later item flag after defrag later is done#12694oranagra merged 1 commit intoredis:unstablefrom
Conversation
There was a problem hiding this comment.
This was interesting/difficult to find. Thanks @roshkhatri for diving deep.
We observed test failures for active defrag didn't stop while running these on loop. And for the failure runs we observed active_defrag_key_hits and active_defrag_key_misses weren't a multiple of dbsize. This lead to discovering that some of the slot scanning were getting skipped due to not resetting the defrag_later_item_in_progress.
|
@oranagra There were two other kind of issues were observed earlier i.e. latency higher than the threshold and frag ratio lower than the threshold. We are running them continuously to measure the variance and possibly tweak the threshold(s) a bit. |
|
thanks. @roshkhatri can you please make a PR? |
Reverts the skipping defrag tests in cluster mode (done in #12672. instead it skips only some defrag tests that are relevant for cluster modes. The test now run well after investigating and making the changes in #12674 and #12694. Co-authored-by: Oran Agra <[email protected]>
Fixing issues described in redis#12672, started after redis#11695 Related to redis#12674 Fixes the `defrag didn't stop' issue. In some cases of how the keys were stored in memory defrag_later_item_in_progress was not getting reset once we finish defragging the later items and we move to the next slot. This stopped the scan to happen in the later slots and did not get
4 participants
Fixing issues described in #12672, started after #11695
Related to #12674
Fixes the `defrag didn't stop' issue.
In some cases of how the keys were stored in memory defrag_later_item_in_progress was not getting reset once we finish defragging the later items and we move to the next slot. This stopped the scan to happen in the later slots and did not get defragged.