minor tweaks to db_crashtest.py settings (#9483)
Summary: I did another pass through running CI jobs. It is uncommon now to see `db_stress` stuck in the setup phase but still happen. One reason was repeatedly reading/verifying checksum on filter blocks when `-cache_index_and_filter_blocks=1` and `-cache_size=1048576`. To address that I increased the cache size. Another reason was having a WAL with many range tombstones and every `db_stress` run using `-avoid_flush_during_recovery=1` (in that scenario, the setup phase spent too much CPU in `rocksdb::MemTable::NewRangeTombstoneIteratorInternal()`). To address that I fixed the `-avoid_flush_during_recovery` setting so it is reevaluated for every `db_stress` run. Pull Request resolved: https://github.com/facebook/rocksdb/pull/9483 Reviewed By: riversand963 Differential Revision: D33922929 Pulled By: ajkr fbshipit-source-id: 0a298ec7c4df6f6b44620233996047a2dc7ee5f3
This commit is contained in:
parent
57418aba51
commit
ad2cab8f0c
@ -36,7 +36,7 @@ default_params = {
|
||||
"bloom_bits": lambda: random.choice([random.randint(0,19),
|
||||
random.lognormvariate(2.3, 1.3)]),
|
||||
"cache_index_and_filter_blocks": lambda: random.randint(0, 1),
|
||||
"cache_size": 1048576,
|
||||
"cache_size": 8388608,
|
||||
"checkpoint_one_in": 1000000,
|
||||
"compression_type": lambda: random.choice(
|
||||
["none", "snappy", "zlib", "lz4", "lz4hc", "xpress", "zstd"]),
|
||||
@ -134,7 +134,7 @@ default_params = {
|
||||
[0, 0, 0, 1024 * 1024, 8 * 1024 * 1024, 128 * 1024 * 1024]),
|
||||
"avoid_unnecessary_blocking_io" : random.randint(0, 1),
|
||||
"write_dbid_to_manifest" : random.randint(0, 1),
|
||||
"avoid_flush_during_recovery" : random.choice(
|
||||
"avoid_flush_during_recovery" : lambda: random.choice(
|
||||
[1 if t == 0 else 0 for t in range(0, 8)]),
|
||||
"max_write_batch_group_size_bytes" : lambda: random.choice(
|
||||
[16, 64, 1024 * 1024, 16 * 1024 * 1024]),
|
||||
|
Loading…
Reference in New Issue
Block a user