Project

General

Profile

Actions

Bug #63280

open

rocksdb: add rocksdb_cf_compact_on_deletion_ratio options

Added by wenjuan wang 7 months ago. Updated 7 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
% Done:

0%

Source:
Tags:
Backport:
Regression:
No
Severity:
2 - major
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

The ceph community defaults to a deletion ratio of 0, which disables triggering compression based on the deletion ratio.

The deletion sliding window optimization does not take effect. Therefore, the deletion ratio configuration item is added. The default value is 0.5

Actions #1

Updated by wenjuan wang 7 months ago

We conducted a performance test, comparing the performance of 'rados ls' in scenarios with a large amount of deletions, both with the introduction of a deletion sliding window and a delete ratio set to 0.5, and without the introduction of a deletion sliding window.

Test method

We started the cluster through vstart, pre-embedded objects of100K size into the cluster through rados bench for7 hours. Finally, the cluster OSD capacity and the number of objects were basically consistent in both tests.

The specific test logic is as follows.Start two rados bench clients, write data for25200 seconds into the pool,After the pre-embedding data is completed, clear the data written by one of the rados bench clients, and then test again.

bash-4.4# cat write-name.txt
wwj-test-bench1
wwj-test-bench2

for name in `cat ./write-name.txt` ; do
        nohup rados bench 1800 write --no-cleanup -t 128 -p wwj-test-pool-0  -b 100K --show-time --run-name "$name" >> writelog 2>&1 &
done

date; time rados -p wwj-test-pool-0 cleanup --run-name wwj-test-bench2

date; time rados ls -p wwj-test-pool-0 > pool-0

Test results

  1. Translation in English:After optimization, the time consumption of rados ls for a single object is reduced by 15.4%, and during the execution of rados ls, disk IOPS, bandwidth, utilization, and osd CPU utilization all decrease.
  2. After the optimization is introduced, during data cleanup, more sst files are compressed, thereby reducing the number of garbage tombstone entries. With the total usage constant, the more times compact is performed, the more garbage data is cleaned up. The usage of store.db is only 19153MB, which is significantly less than the 22495 MB in the benchmark test.
    1. During the benchmark test, before cleaning the data, store.db used 34518 MB, and after cleaning the data, store.db used 22495 MB, a decrease of 12023MB.
    2. After the optimization is introduced, before cleaning the data, store.db used 34641 MB, and after cleaning the data, store.db used 19153 MB, a decrease of 15488MB.
  3. After the optimization is introduced, after cleaning the data, execute rados ls 3 times, each execution result is better than the previous one, where the second time is 7% better than the first time, and the third time is 0.6% better than the second time.
Actions #2

Updated by Igor Fedotov 7 months ago

  • Status changed from New to In Progress
  • Pull request ID set to 54135
Actions

Also available in: Atom PDF