This pause occurs between the delete (the addition of the tombstone), and the GET that prompts the reap. It was found in timeout based delete_mode, the race between the PUT of the tomb and the GET could result in tombstones lingering, and then those tombstones caused issues in full-sync.
The root cause of the tombstones causing full-sync problems has now been resolved: https://github.com/basho/riak_kv/issues/1813. Therefore the necessity of this pause is no longer clear. Volume erases have been tested with this reduced to 2ms with no issues.
Clearing this to 0, would though reduce any constraint on the performance of the eraser. There remains some benefits in the eraser being a background process with some (albeit accidental rate-limiting).
The proposal is to reduce this pause from 10ms to 2s. Further, the same pause should be applied in the reaper, so that riak_kv_reaper works at a consistent pace to the riak_kv_eraser.
martinsumner
commented
2 years ago
The
riak_kv_deleteprocess has atombstone_pause(default 10ms) added as part of a general set of improvements in the TTAAE full-sync process.This pause occurs between the delete (the addition of the tombstone), and the GET that prompts the reap. It was found in timeout based
delete_mode, the race between the PUT of the tomb and the GET could result in tombstones lingering, and then those tombstones caused issues in full-sync.The root cause of the tombstones causing full-sync problems has now been resolved: https://github.com/basho/riak_kv/issues/1813. Therefore the necessity of this pause is no longer clear. Volume erases have been tested with this reduced to 2ms with no issues.
Clearing this to 0, would though reduce any constraint on the performance of the eraser. There remains some benefits in the eraser being a background process with some (albeit accidental rate-limiting).
The proposal is to reduce this pause from 10ms to 2s. Further, the same pause should be applied in the reaper, so that riak_kv_reaper works at a consistent pace to the riak_kv_eraser.