2019-12-09 07:49:32 +00:00
|
|
|
// Copyright (c) 2011-present, Facebook, Inc. All rights reserved.
|
|
|
|
// This source code is licensed under both the GPLv2 (found in the
|
|
|
|
// COPYING file in the root directory) and Apache 2.0 License
|
|
|
|
// (found in the LICENSE.Apache file in the root directory).
|
|
|
|
//
|
|
|
|
// Copyright (c) 2011 The LevelDB Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style license that can be
|
|
|
|
// found in the LICENSE file. See the AUTHORS file for names of contributors.
|
|
|
|
|
Add missing db crash options (#12414)
Summary:
**Context/Summary:**
We are doing a sweep in all public options, including but not limited to the `Options`, `Read/WriteOptions`, `IngestExternalFileOptions`, cache options.., to find and add the uncovered ones into db crash. The options included in this PR require minimum changes to db crash other than adding the options themselves.
A bonus change: to surface new issues by improved coverage in stderror, we decided to fail/terminate crash test for manual compactions (CompactFiles, CompactRange()) on meaningful errors. See https://github.com/facebook/rocksdb/pull/12414/files#diff-5c4ced6afb6a90e27fec18ab03b2cd89e8f99db87791b4ecc6fa2694284d50c0R2528-R2532, https://github.com/facebook/rocksdb/pull/12414/files#diff-5c4ced6afb6a90e27fec18ab03b2cd89e8f99db87791b4ecc6fa2694284d50c0R2330-R2336 for more.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12414
Test Plan:
- Run `python3 ./tools/db_crashtest.py --simple blackbox` for 10 minutes to ensure no trivial failure
- Run `python3 tools/db_crashtest.py --simple blackbox --compact_files_one_in=1 --compact_range_one_in=1 --read_fault_one_in=1 --write_fault_one_in=1 --interval=50` for a while to ensure the bonus change does not result in trivial crash/termination of stress test
Reviewed By: ajkr, jowlyzhang, cbi42
Differential Revision: D54691774
Pulled By: hx235
fbshipit-source-id: 50443dfb6aaabd8e24c79a2e42b68c6de877be88
2024-03-13 00:24:12 +00:00
|
|
|
#include "rocksdb/cache.h"
|
|
|
|
#include "rocksdb/options.h"
|
|
|
|
#include "rocksdb/utilities/backup_engine.h"
|
2019-12-09 07:49:32 +00:00
|
|
|
#ifdef GFLAGS
|
|
|
|
#include "db_stress_tool/db_stress_common.h"
|
|
|
|
|
|
|
|
static bool ValidateUint32Range(const char* flagname, uint64_t value) {
|
|
|
|
if (value > std::numeric_limits<uint32_t>::max()) {
|
|
|
|
fprintf(stderr, "Invalid value for --%s: %lu, overflow\n", flagname,
|
|
|
|
(unsigned long)value);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2021-10-11 23:22:10 +00:00
|
|
|
DEFINE_uint64(seed, 2341234,
|
|
|
|
"Seed for PRNG. When --nooverwritepercent is "
|
|
|
|
"nonzero and --expected_values_dir is nonempty, this value "
|
|
|
|
"must be fixed across invocations.");
|
2019-12-09 07:49:32 +00:00
|
|
|
static const bool FLAGS_seed_dummy __attribute__((__unused__)) =
|
|
|
|
RegisterFlagValidator(&FLAGS_seed, &ValidateUint32Range);
|
|
|
|
|
|
|
|
DEFINE_bool(read_only, false, "True if open DB in read-only mode during tests");
|
|
|
|
|
|
|
|
DEFINE_int64(max_key, 1 * KB * KB,
|
|
|
|
"Max number of key/values to place in database");
|
|
|
|
|
2020-01-10 05:25:40 +00:00
|
|
|
DEFINE_int32(max_key_len, 3, "Maximum length of a key in 8-byte units");
|
|
|
|
|
2024-03-18 16:05:11 +00:00
|
|
|
DEFINE_uint64(max_sequential_skip_in_iterations,
|
|
|
|
ROCKSDB_NAMESPACE::Options().max_sequential_skip_in_iterations,
|
|
|
|
"Iterator will reseek after scanning this number of keys with"
|
|
|
|
"the same user key during Next/Prev().");
|
|
|
|
|
2020-01-10 05:25:40 +00:00
|
|
|
DEFINE_string(key_len_percent_dist, "",
|
|
|
|
"Percentages of keys of various lengths. For example, 1,30,69 "
|
|
|
|
"means 1% of keys are 8 bytes, 30% are 16 bytes, and 69% are "
|
|
|
|
"24 bytes. If not specified, it will be evenly distributed");
|
|
|
|
|
|
|
|
DEFINE_int32(key_window_scale_factor, 10,
|
2022-06-03 03:04:33 +00:00
|
|
|
"This value will be multiplied by 100 to come up with a window "
|
|
|
|
"size for varying the key length");
|
2020-01-10 05:25:40 +00:00
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_int32(column_families, 10, "Number of column families");
|
|
|
|
|
2019-12-16 21:59:21 +00:00
|
|
|
DEFINE_double(
|
|
|
|
hot_key_alpha, 0,
|
|
|
|
"Use Zipfian distribution to generate the key "
|
|
|
|
"distribution. If it is not specified, write path will use random "
|
|
|
|
"distribution to generate the keys. The parameter is [0, double_max]). "
|
|
|
|
"However, the larger alpha is, the more shewed will be. If alpha is "
|
|
|
|
"larger than 2, it is likely that only 1 key will be accessed. The "
|
|
|
|
"Recommended value is [0.8-1.5]. The distribution is also related to "
|
|
|
|
"max_key and total iterations of generating the hot key. ");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_string(
|
|
|
|
options_file, "",
|
|
|
|
"The path to a RocksDB options file. If specified, then db_stress will "
|
|
|
|
"run with the RocksDB options in the default column family of the "
|
|
|
|
"specified options file. Note that, when an options file is provided, "
|
|
|
|
"db_stress will ignore the flag values for all options that may be passed "
|
|
|
|
"via options file.");
|
|
|
|
|
|
|
|
DEFINE_int64(
|
|
|
|
active_width, 0,
|
|
|
|
"Number of keys in active span of the key-range at any given time. The "
|
|
|
|
"span begins with its left endpoint at key 0, gradually moves rightwards, "
|
|
|
|
"and ends with its right endpoint at max_key. If set to 0, active_width "
|
|
|
|
"will be sanitized to be equal to max_key.");
|
|
|
|
|
|
|
|
// TODO(noetzli) Add support for single deletes
|
|
|
|
DEFINE_bool(test_batches_snapshots, false,
|
|
|
|
"If set, the test uses MultiGet(), MultiPut() and MultiDelete()"
|
|
|
|
" which read/write/delete multiple keys in a batch. In this mode,"
|
|
|
|
" we do not verify db content by comparing the content with the "
|
|
|
|
"pre-allocated array. Instead, we do partial verification inside"
|
|
|
|
" MultiGet() by checking various values in a batch. Benefit of"
|
|
|
|
" this mode:\n"
|
|
|
|
"\t(a) No need to acquire mutexes during writes (less cache "
|
|
|
|
"flushes in multi-core leading to speed up)\n"
|
|
|
|
"\t(b) No long validation at the end (more speed up)\n"
|
|
|
|
"\t(c) Test snapshot and atomicity of batch writes");
|
|
|
|
|
|
|
|
DEFINE_bool(atomic_flush, false,
|
|
|
|
"If set, enables atomic flush in the options.\n");
|
|
|
|
|
Add manual_wal_flush, FlushWAL() to stress/crash test (#10698)
Summary:
**Context/Summary:**
Introduce `manual_wal_flush_one_in` as titled.
- When `manual_wal_flush_one_in > 0`, we also need tracing to correctly verify recovery because WAL data can be lost in this case when `FlushWAL()` is not explicitly called by users of RocksDB (in our case, db stress) and the recovery from such potential WAL data loss is a prefix recovery that requires tracing to verify. As another consequence, we need to disable features can't run under unsync data loss with `manual_wal_flush_one_in`
Incompatibilities fixed along the way:
```
db_stress: db/db_impl/db_impl_open.cc:2063: static rocksdb::Status rocksdb::DBImpl::Open(const rocksdb::DBOptions&, const string&, const std::vector<rocksdb::ColumnFamilyDescriptor>&, std::vector<rocksdb::ColumnFamilyHandle*>*, rocksdb::DB**, bool, bool): Assertion `impl->TEST_WALBufferIsEmpty()' failed.
```
- It turns out that `Writer::AddCompressionTypeRecord` before this assertion `EmitPhysicalRecord(kSetCompressionType, encode.data(), encode.size());` but do not trigger flush if `manual_wal_flush` is set . This leads to `impl->TEST_WALBufferIsEmpty()' is false.
- As suggested, assertion is removed and violation case is handled by `FlushWAL(sync=true)` along with refactoring `TEST_WALBufferIsEmpty()` to be `WALBufferIsEmpty()` since it is used in prod code now.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/10698
Test Plan:
- Locally running `python3 tools/db_crashtest.py blackbox --manual_wal_flush_one_in=1 --manual_wal_flush=1 --sync_wal_one_in=100 --atomic_flush=1 --flush_one_in=100 --column_families=3`
- Joined https://github.com/facebook/rocksdb/pull/10624 in auto CI testings with all RocksDB stress/crash test jobs
Reviewed By: ajkr
Differential Revision: D39593752
Pulled By: ajkr
fbshipit-source-id: 3a2135bb792c52d2ffa60257d4fbc557fb04d2ce
2022-09-30 22:48:33 +00:00
|
|
|
DEFINE_int32(
|
|
|
|
manual_wal_flush_one_in, 0,
|
|
|
|
"If non-zero, then `FlushWAL(bool sync)`, where `bool sync` is randomly "
|
|
|
|
"decided, will be explictly called in db stress once for every N ops "
|
|
|
|
"on average. Setting `manual_wal_flush_one_in` to be greater than 0 "
|
|
|
|
"implies `Options::manual_wal_flush = true` is set.");
|
|
|
|
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
DEFINE_int32(lock_wal_one_in, 1000000,
|
|
|
|
"If non-zero, then `LockWAL()` + `UnlockWAL()` will be called in "
|
|
|
|
"db_stress once for every N ops on average.");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_bool(test_cf_consistency, false,
|
|
|
|
"If set, runs the stress test dedicated to verifying writes to "
|
|
|
|
"multiple column families are consistent. Setting this implies "
|
|
|
|
"`atomic_flush=true` is set true if `disable_wal=false`.\n");
|
|
|
|
|
2021-12-14 21:33:16 +00:00
|
|
|
DEFINE_bool(test_multi_ops_txns, false,
|
|
|
|
"If set, runs stress test dedicated to verifying multi-ops "
|
|
|
|
"transactions on a simple relational table with primary and "
|
|
|
|
"secondary index.");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_int32(threads, 32, "Number of concurrent threads to run.");
|
|
|
|
|
|
|
|
DEFINE_int32(ttl, -1,
|
|
|
|
"Opens the db with this ttl value if this is not -1. "
|
|
|
|
"Carefully specify a large value such that verifications on "
|
|
|
|
"deleted values don't fail");
|
|
|
|
|
|
|
|
DEFINE_int32(value_size_mult, 8,
|
|
|
|
"Size of value will be this number times rand_int(1,3) bytes");
|
|
|
|
|
|
|
|
DEFINE_int32(compaction_readahead_size, 0, "Compaction readahead size");
|
|
|
|
|
|
|
|
DEFINE_bool(enable_pipelined_write, false, "Pipeline WAL/memtable writes");
|
|
|
|
|
|
|
|
DEFINE_bool(verify_before_write, false, "Verify before write");
|
|
|
|
|
|
|
|
DEFINE_bool(histogram, false, "Print histogram of operation timings");
|
|
|
|
|
|
|
|
DEFINE_bool(destroy_db_initially, true,
|
|
|
|
"Destroys the database dir before start if this is true");
|
|
|
|
|
|
|
|
DEFINE_bool(verbose, false, "Verbose");
|
|
|
|
|
|
|
|
DEFINE_bool(progress_reports, true,
|
|
|
|
"If true, db_stress will report number of finished operations");
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
DEFINE_uint64(db_write_buffer_size,
|
|
|
|
ROCKSDB_NAMESPACE::Options().db_write_buffer_size,
|
2019-12-09 07:49:32 +00:00
|
|
|
"Number of bytes to buffer in all memtables before compacting");
|
|
|
|
|
2023-10-10 20:12:18 +00:00
|
|
|
DEFINE_bool(use_write_buffer_manager, false,
|
|
|
|
"Charge WriteBufferManager memory to the block cache");
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
DEFINE_int32(
|
|
|
|
write_buffer_size,
|
|
|
|
static_cast<int32_t>(ROCKSDB_NAMESPACE::Options().write_buffer_size),
|
|
|
|
"Number of bytes to buffer in memtable before compacting");
|
2019-12-09 07:49:32 +00:00
|
|
|
|
|
|
|
DEFINE_int32(max_write_buffer_number,
|
2020-02-20 20:07:53 +00:00
|
|
|
ROCKSDB_NAMESPACE::Options().max_write_buffer_number,
|
2019-12-09 07:49:32 +00:00
|
|
|
"The number of in-memory memtables. "
|
|
|
|
"Each memtable is of size FLAGS_write_buffer_size.");
|
|
|
|
|
|
|
|
DEFINE_int32(min_write_buffer_number_to_merge,
|
2020-02-20 20:07:53 +00:00
|
|
|
ROCKSDB_NAMESPACE::Options().min_write_buffer_number_to_merge,
|
2019-12-09 07:49:32 +00:00
|
|
|
"The minimum number of write buffers that will be merged together "
|
|
|
|
"before writing to storage. This is cheap because it is an "
|
|
|
|
"in-memory merge. If this feature is not enabled, then all these "
|
|
|
|
"write buffers are flushed to L0 as separate files and this "
|
|
|
|
"increases read amplification because a get request has to check "
|
|
|
|
"in all of these files. Also, an in-memory merge may result in "
|
|
|
|
"writing less data to storage if there are duplicate records in"
|
|
|
|
" each of these individual write buffers.");
|
|
|
|
|
|
|
|
DEFINE_int32(max_write_buffer_number_to_maintain,
|
2020-02-20 20:07:53 +00:00
|
|
|
ROCKSDB_NAMESPACE::Options().max_write_buffer_number_to_maintain,
|
2019-12-09 07:49:32 +00:00
|
|
|
"The total maximum number of write buffers to maintain in memory "
|
|
|
|
"including copies of buffers that have already been flushed. "
|
|
|
|
"Unlike max_write_buffer_number, this parameter does not affect "
|
|
|
|
"flushing. This controls the minimum amount of write history "
|
|
|
|
"that will be available in memory for conflict checking when "
|
|
|
|
"Transactions are used. If this value is too low, some "
|
|
|
|
"transactions may fail at commit time due to not being able to "
|
|
|
|
"determine whether there were any write conflicts. Setting this "
|
|
|
|
"value to 0 will cause write buffers to be freed immediately "
|
|
|
|
"after they are flushed. If this value is set to -1, "
|
|
|
|
"'max_write_buffer_number' will be used.");
|
|
|
|
|
|
|
|
DEFINE_int64(max_write_buffer_size_to_maintain,
|
2020-02-20 20:07:53 +00:00
|
|
|
ROCKSDB_NAMESPACE::Options().max_write_buffer_size_to_maintain,
|
2019-12-09 07:49:32 +00:00
|
|
|
"The total maximum size of write buffers to maintain in memory "
|
|
|
|
"including copies of buffers that have already been flushed. "
|
|
|
|
"Unlike max_write_buffer_number, this parameter does not affect "
|
|
|
|
"flushing. This controls the minimum amount of write history "
|
|
|
|
"that will be available in memory for conflict checking when "
|
|
|
|
"Transactions are used. If this value is too low, some "
|
|
|
|
"transactions may fail at commit time due to not being able to "
|
|
|
|
"determine whether there were any write conflicts. Setting this "
|
|
|
|
"value to 0 will cause write buffers to be freed immediately "
|
|
|
|
"after they are flushed. If this value is set to -1, "
|
|
|
|
"'max_write_buffer_number' will be used.");
|
|
|
|
|
|
|
|
DEFINE_double(memtable_prefix_bloom_size_ratio,
|
2020-02-20 20:07:53 +00:00
|
|
|
ROCKSDB_NAMESPACE::Options().memtable_prefix_bloom_size_ratio,
|
2019-12-09 07:49:32 +00:00
|
|
|
"creates prefix blooms for memtables, each with size "
|
|
|
|
"`write_buffer_size * memtable_prefix_bloom_size_ratio`.");
|
|
|
|
|
|
|
|
DEFINE_bool(memtable_whole_key_filtering,
|
2020-02-20 20:07:53 +00:00
|
|
|
ROCKSDB_NAMESPACE::Options().memtable_whole_key_filtering,
|
2019-12-09 07:49:32 +00:00
|
|
|
"Enable whole key filtering in memtables.");
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
DEFINE_int32(open_files, ROCKSDB_NAMESPACE::Options().max_open_files,
|
2019-12-09 07:49:32 +00:00
|
|
|
"Maximum number of files to keep open at the same time "
|
|
|
|
"(use default if == 0)");
|
|
|
|
|
2023-10-10 20:12:18 +00:00
|
|
|
DEFINE_uint64(compressed_secondary_cache_size, 0,
|
|
|
|
"Number of bytes to use as a cache of compressed data."
|
|
|
|
" 0 means use default settings.");
|
Avoid overwriting options loaded from OPTIONS (#9943)
Summary:
This is similar to https://github.com/facebook/rocksdb/issues/9862, including the following fixes/refactoring:
1. If OPTIONS file is specified via `-options_file`, majority of options will be loaded from the file. We should not
overwrite options that have been loaded from the file. Instead, we configure only fields of options which are
shared objects and not set by the OPTIONS file. We also configure a few fields, e.g. `create_if_missing` necessary
for stress test to run.
2. Refactor options initialization into three functions, `InitializeOptionsFromFile()`, `InitializeOptionsFromFlags()`
and `InitializeOptionsGeneral()` similar to db_bench. I hope they can be shared in the future. The high-level logic is
as follows:
```cpp
if (!InitializeOptionsFromFile(...)) {
InitializeOptionsFromFlags(...);
}
InitializeOptionsGeneral(...);
```
3. Currently, the setting for `block_cache_compressed` does not seem correct because it by default specifies a
size of `numeric_limits<size_t>::max()` ((size_t)-1). According to code comments, `-1` indicates default value,
which should be referring to `num_shard_bits` argument.
4. Clarify `fail_if_options_file_error`.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9943
Test Plan:
1. make check
2. Run stress tests, and manually check generated OPTIONS file and compare them with input OPTIONS files
Reviewed By: jay-zhuang
Differential Revision: D36133769
Pulled By: riversand963
fbshipit-source-id: 35dacdc090a0a72c922907170cd132b9ecaa073e
2022-05-18 19:43:50 +00:00
|
|
|
|
2023-10-10 20:12:18 +00:00
|
|
|
DEFINE_int32(compressed_secondary_cache_numshardbits, -1,
|
|
|
|
"Number of shards for the compressed secondary cache is 2 ** "
|
|
|
|
"compressed_secondary_cache_numshardbits. "
|
|
|
|
"Negative value means default settings. This is applied only "
|
|
|
|
"if compressed_secondary_cache_size is greater than 0.");
|
|
|
|
|
|
|
|
DEFINE_double(compressed_secondary_cache_ratio, 0.0,
|
|
|
|
"Fraction of block cache memory budget to use for compressed "
|
|
|
|
"secondary cache");
|
|
|
|
|
|
|
|
DEFINE_int32(secondary_cache_update_interval, 30 * 1000 * 1000,
|
|
|
|
"Interval between modification of secondary cache parameters, in "
|
|
|
|
"microseconds");
|
2019-12-09 07:49:32 +00:00
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
DEFINE_int32(compaction_style, ROCKSDB_NAMESPACE::Options().compaction_style,
|
|
|
|
"");
|
2019-12-09 07:49:32 +00:00
|
|
|
|
2022-07-01 05:56:58 +00:00
|
|
|
DEFINE_int32(compaction_pri, ROCKSDB_NAMESPACE::Options().compaction_pri,
|
|
|
|
"Which file from a level should be picked to merge to the next "
|
|
|
|
"level in level-based compaction");
|
|
|
|
|
2020-05-07 01:06:04 +00:00
|
|
|
DEFINE_int32(num_levels, ROCKSDB_NAMESPACE::Options().num_levels,
|
|
|
|
"Number of levels in the DB");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_int32(level0_file_num_compaction_trigger,
|
2020-02-20 20:07:53 +00:00
|
|
|
ROCKSDB_NAMESPACE::Options().level0_file_num_compaction_trigger,
|
2019-12-09 07:49:32 +00:00
|
|
|
"Level0 compaction start trigger");
|
|
|
|
|
|
|
|
DEFINE_int32(level0_slowdown_writes_trigger,
|
2020-02-20 20:07:53 +00:00
|
|
|
ROCKSDB_NAMESPACE::Options().level0_slowdown_writes_trigger,
|
2019-12-09 07:49:32 +00:00
|
|
|
"Number of files in level-0 that will slow down writes");
|
|
|
|
|
|
|
|
DEFINE_int32(level0_stop_writes_trigger,
|
2020-02-20 20:07:53 +00:00
|
|
|
ROCKSDB_NAMESPACE::Options().level0_stop_writes_trigger,
|
2019-12-09 07:49:32 +00:00
|
|
|
"Number of files in level-0 that will trigger put stop.");
|
|
|
|
|
|
|
|
DEFINE_int32(block_size,
|
2020-02-20 20:07:53 +00:00
|
|
|
static_cast<int32_t>(
|
|
|
|
ROCKSDB_NAMESPACE::BlockBasedTableOptions().block_size),
|
2019-12-09 07:49:32 +00:00
|
|
|
"Number of bytes in a block.");
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
DEFINE_int32(format_version,
|
|
|
|
static_cast<int32_t>(
|
|
|
|
ROCKSDB_NAMESPACE::BlockBasedTableOptions().format_version),
|
|
|
|
"Format version of SST files.");
|
2019-12-09 07:49:32 +00:00
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
DEFINE_int32(
|
|
|
|
index_block_restart_interval,
|
|
|
|
ROCKSDB_NAMESPACE::BlockBasedTableOptions().index_block_restart_interval,
|
|
|
|
"Number of keys between restart points "
|
|
|
|
"for delta encoding of keys in index block.");
|
2019-12-09 07:49:32 +00:00
|
|
|
|
2022-03-17 02:00:04 +00:00
|
|
|
DEFINE_bool(disable_auto_compactions,
|
|
|
|
ROCKSDB_NAMESPACE::Options().disable_auto_compactions,
|
|
|
|
"If true, RocksDB internally will not trigger compactions.");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_int32(max_background_compactions,
|
2020-02-20 20:07:53 +00:00
|
|
|
ROCKSDB_NAMESPACE::Options().max_background_compactions,
|
2019-12-09 07:49:32 +00:00
|
|
|
"The maximum number of concurrent background compactions "
|
|
|
|
"that can occur in parallel.");
|
|
|
|
|
|
|
|
DEFINE_int32(num_bottom_pri_threads, 0,
|
|
|
|
"The number of threads in the bottom-priority thread pool (used "
|
|
|
|
"by universal compaction only).");
|
|
|
|
|
|
|
|
DEFINE_int32(compaction_thread_pool_adjust_interval, 0,
|
|
|
|
"The interval (in milliseconds) to adjust compaction thread pool "
|
|
|
|
"size. Don't change it periodically if the value is 0.");
|
|
|
|
|
|
|
|
DEFINE_int32(compaction_thread_pool_variations, 2,
|
|
|
|
"Range of background thread pool size variations when adjusted "
|
|
|
|
"periodically.");
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
DEFINE_int32(max_background_flushes,
|
|
|
|
ROCKSDB_NAMESPACE::Options().max_background_flushes,
|
2019-12-09 07:49:32 +00:00
|
|
|
"The maximum number of concurrent background flushes "
|
|
|
|
"that can occur in parallel.");
|
|
|
|
|
|
|
|
DEFINE_int32(universal_size_ratio, 0,
|
|
|
|
"The ratio of file sizes that trigger"
|
|
|
|
" compaction in universal style");
|
|
|
|
|
|
|
|
DEFINE_int32(universal_min_merge_width, 0,
|
|
|
|
"The minimum number of files to "
|
|
|
|
"compact in universal style compaction");
|
|
|
|
|
|
|
|
DEFINE_int32(universal_max_merge_width, 0,
|
|
|
|
"The max number of files to compact"
|
|
|
|
" in universal style compaction");
|
|
|
|
|
|
|
|
DEFINE_int32(universal_max_size_amplification_percent, 0,
|
|
|
|
"The max size amplification for universal style compaction");
|
|
|
|
|
Improve universal compaction sorted-run trigger (#12477)
Summary:
Universal compaction currently uses `level0_file_num_compaction_trigger` for two purposes:
1. the trigger for checking if there is any compaction to do, and
2. the limit on the number of sorted runs. RocksDB will do compaction to keep the number of sorted runs no more than the value of this option.
This can make the option inflexible. A value that is too small causes higher write amp: more compactions to reduce the number of sorted runs. A value that is too big delays potential compaction work and causes worse read performance. This PR introduce an option `CompactionOptionsUniversal::max_read_amp` for only the second purpose: to specify
the hard limit on the number of sorted runs.
For backward compatibility, `max_read_amp = -1` by default, which means to fallback to the current behavior.
When `max_read_amp > 0`,`level0_file_num_compaction_trigger` will only serve as a trigger to find potential compaction.
When `max_read_amp = 0`, RocksDB will auto-tune the limit on the number of sorted runs. The estimation is based on DB size, write_buffer_size and size_ratio, so it is adaptive to the size change of the DB. See more in `UniversalCompactionBuilder::PickCompaction()`.
Alternatively, users now can configure `max_read_amp` to a very big value and keep `level0_file_num_compaction_trigger` small. This will allow `size_ratio` and `max_size_amplification_percent` to control the number of sorted runs. This essentially disables compactions with reason kUniversalSortedRunNum.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12477
Test Plan:
* new unit test
* existing unit test for default behavior
* updated crash test with the new option
* benchmark:
* Create a DB that is roughly 24GB in the last level. When `max_read_amp = 0`, we estimate that the DB needs 9 levels to avoid excessive compactions to reduce the number of sorted runs.
* We then run fillrandom to ingest another 24GB data to compare write amp.
* case 1: small level0 trigger: `level0_file_num_compaction_trigger=5, max_read_amp=-1`
* write-amp: 4.8
* case 2: auto-tune: `level0_file_num_compaction_trigger=5, max_read_amp=0`
* write-amp: 3.6
* case 3: auto-tune with minimal trigger: `level0_file_num_compaction_trigger=1, max_read_amp=0`
* write-amp: 3.8
* case 4: hard-code a good value for trigger: `level0_file_num_compaction_trigger=9`
* write-amp: 2.8
```
Case 1:
** Compaction Stats [default] **
Level Files Size Score Read(GB) Rn(GB) Rnp1(GB) Write(GB) Wnew(GB) Moved(GB) W-Amp Rd(MB/s) Wr(MB/s) Comp(sec) CompMergeCPU(sec) Comp(cnt) Avg(sec) KeyIn KeyDrop Rblob(GB) Wblob(GB)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
L0 0/0 0.00 KB 1.0 0.0 0.0 0.0 22.6 22.6 0.0 1.0 0.0 163.2 141.94 111.10 108 1.314 0 0 0.0 0.0
L45 8/0 1.81 GB 0.0 39.6 11.1 28.5 39.3 10.8 0.0 3.5 209.0 207.3 194.25 191.29 43 4.517 348M 2498K 0.0 0.0
L46 13/0 3.12 GB 0.0 15.3 9.5 5.8 15.0 9.3 0.0 1.6 203.1 199.3 77.13 75.88 16 4.821 134M 2362K 0.0 0.0
L47 19/0 4.68 GB 0.0 15.4 10.5 4.9 14.7 9.8 0.0 1.4 204.0 194.9 77.38 76.15 8 9.673 135M 5920K 0.0 0.0
L48 38/0 9.42 GB 0.0 19.6 11.7 7.9 17.3 9.4 0.0 1.5 206.5 182.3 97.15 95.02 4 24.287 172M 20M 0.0 0.0
L49 91/0 22.70 GB 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.00 0.00 0 0.000 0 0 0.0 0.0
Sum 169/0 41.74 GB 0.0 89.9 42.9 47.0 109.0 61.9 0.0 4.8 156.7 189.8 587.85 549.45 179 3.284 791M 31M 0.0 0.0
Case 2:
** Compaction Stats [default] **
Level Files Size Score Read(GB) Rn(GB) Rnp1(GB) Write(GB) Wnew(GB) Moved(GB) W-Amp Rd(MB/s) Wr(MB/s) Comp(sec) CompMergeCPU(sec) Comp(cnt) Avg(sec) KeyIn KeyDrop Rblob(GB) Wblob(GB)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
L0 1/0 214.47 MB 1.2 0.0 0.0 0.0 22.6 22.6 0.0 1.0 0.0 164.5 140.81 109.98 108 1.304 0 0 0.0 0.0
L44 0/0 0.00 KB 0.0 1.3 1.3 0.0 1.2 1.2 0.0 1.0 206.1 204.9 6.24 5.98 3 2.081 11M 51K 0.0 0.0
L45 4/0 844.36 MB 0.0 7.1 5.4 1.7 7.0 5.4 0.0 1.3 194.6 192.9 37.41 36.00 13 2.878 62M 489K 0.0 0.0
L46 11/0 2.57 GB 0.0 14.6 9.8 4.8 14.3 9.5 0.0 1.5 193.7 189.8 77.09 73.54 17 4.535 128M 2411K 0.0 0.0
L47 24/0 5.81 GB 0.0 19.8 12.0 7.8 18.8 11.0 0.0 1.6 191.4 181.1 106.19 101.21 9 11.799 174M 9166K 0.0 0.0
L48 38/0 9.42 GB 0.0 19.6 11.8 7.9 17.3 9.4 0.0 1.5 197.3 173.6 101.97 97.23 4 25.491 172M 20M 0.0 0.0
L49 91/0 22.70 GB 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.00 0.00 0 0.000 0 0 0.0 0.0
Sum 169/0 41.54 GB 0.0 62.4 40.3 22.1 81.3 59.2 0.0 3.6 136.1 177.2 469.71 423.94 154 3.050 549M 32M 0.0 0.0
Case 3:
** Compaction Stats [default] **
Level Files Size Score Read(GB) Rn(GB) Rnp1(GB) Write(GB) Wnew(GB) Moved(GB) W-Amp Rd(MB/s) Wr(MB/s) Comp(sec) CompMergeCPU(sec) Comp(cnt) Avg(sec) KeyIn KeyDrop Rblob(GB) Wblob(GB)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
L0 0/0 0.00 KB 5.0 0.0 0.0 0.0 22.6 22.6 0.0 1.0 0.0 163.8 141.43 111.13 108 1.310 0 0 0.0 0.0
L44 0/0 0.00 KB 0.0 0.8 0.8 0.0 0.8 0.8 0.0 1.0 201.4 200.2 4.26 4.19 2 2.130 7360K 33K 0.0 0.0
L45 4/0 844.38 MB 0.0 6.3 5.0 1.2 6.2 5.0 0.0 1.2 202.0 200.3 31.81 31.50 12 2.651 55M 403K 0.0 0.0
L46 7/0 1.62 GB 0.0 13.3 8.8 4.6 13.1 8.6 0.0 1.5 198.9 195.7 68.72 67.89 17 4.042 117M 1696K 0.0 0.0
L47 24/0 5.81 GB 0.0 21.7 12.9 8.8 20.6 11.8 0.0 1.6 198.5 188.6 112.04 109.97 12 9.336 191M 9352K 0.0 0.0
L48 41/0 10.14 GB 0.0 24.8 13.0 11.8 21.9 10.1 0.0 1.7 198.6 175.6 127.88 125.36 6 21.313 218M 25M 0.0 0.0
L49 91/0 22.70 GB 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.00 0.00 0 0.000 0 0 0.0 0.0
Sum 167/0 41.10 GB 0.0 67.0 40.5 26.4 85.4 58.9 0.0 3.8 141.1 179.8 486.13 450.04 157 3.096 589M 36M 0.0 0.0
Case 4:
** Compaction Stats [default] **
Level Files Size Score Read(GB) Rn(GB) Rnp1(GB) Write(GB) Wnew(GB) Moved(GB) W-Amp Rd(MB/s) Wr(MB/s) Comp(sec) CompMergeCPU(sec) Comp(cnt) Avg(sec) KeyIn KeyDrop Rblob(GB) Wblob(GB)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
L0 0/0 0.00 KB 0.7 0.0 0.0 0.0 22.6 22.6 0.0 1.0 0.0 158.6 146.02 114.68 108 1.352 0 0 0.0 0.0
L42 0/0 0.00 KB 0.0 1.7 1.7 0.0 1.7 1.7 0.0 1.0 185.4 184.3 9.25 8.96 4 2.314 14M 67K 0.0 0.0
L43 0/0 0.00 KB 0.0 2.5 2.5 0.0 2.5 2.5 0.0 1.0 197.8 195.6 13.01 12.65 4 3.253 22M 202K 0.0 0.0
L44 4/0 844.40 MB 0.0 4.2 4.2 0.0 4.1 4.1 0.0 1.0 188.1 185.1 22.81 21.89 5 4.562 36M 503K 0.0 0.0
L45 13/0 3.12 GB 0.0 7.5 6.5 1.0 7.2 6.2 0.0 1.1 188.7 181.8 40.69 39.32 5 8.138 65M 2282K 0.0 0.0
L46 17/0 4.18 GB 0.0 8.3 7.1 1.2 7.9 6.6 0.0 1.1 192.2 181.8 44.23 43.06 4 11.058 73M 3846K 0.0 0.0
L47 22/0 5.34 GB 0.0 8.9 7.5 1.4 8.2 6.8 0.0 1.1 189.1 174.1 48.12 45.37 3 16.041 78M 6098K 0.0 0.0
L48 27/0 6.58 GB 0.0 9.2 7.6 1.6 8.2 6.6 0.0 1.1 195.2 172.9 48.52 47.11 2 24.262 81M 9217K 0.0 0.0
L49 91/0 22.70 GB 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.00 0.00 0 0.000 0 0 0.0 0.0
Sum 174/0 42.74 GB 0.0 42.3 37.0 5.3 62.4 57.1 0.0 2.8 116.3 171.3 372.66 333.04 135 2.760 372M 22M 0.0 0.0
setup:
./db_bench --benchmarks=fillseq,compactall,waitforcompaction --num=200000000 --compression_type=none --disable_wal=1 --compaction_style=1 --num_levels=50 --target_file_size_base=268435456 --max_compaction_bytes=6710886400 --level0_file_num_compaction_trigger=10 --write_buffer_size=268435456 --seed 1708494134896523
benchmark:
./db_bench --benchmarks=overwrite,waitforcompaction,stats --num=200000000 --compression_type=none --disable_wal=1 --compaction_style=1 --write_buffer_size=268435456 --level0_file_num_compaction_trigger=5 --target_file_size_base=268435456 --use_existing_db=1 --num_levels=50 --writes=200000000 --universal_max_read_amp=-1 --seed=1716488324800233
```
Reviewed By: ajkr
Differential Revision: D55370922
Pulled By: cbi42
fbshipit-source-id: 9be69979126b840d08e93e7059260e76a878bb2a
2024-05-24 17:10:31 +00:00
|
|
|
DEFINE_int32(universal_max_read_amp, -1,
|
|
|
|
"The limit on the number of sorted runs");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_int32(clear_column_family_one_in, 1000000,
|
|
|
|
"With a chance of 1/N, delete a column family and then recreate "
|
|
|
|
"it again. If N == 0, never drop/create column families. "
|
|
|
|
"When test_batches_snapshots is true, this flag has no effect");
|
|
|
|
|
2024-04-16 22:43:26 +00:00
|
|
|
DEFINE_int32(
|
|
|
|
get_live_files_apis_one_in, 1000000,
|
|
|
|
"With a chance of 1/N, call GetLiveFiles(), GetLiveFilesMetaData() and "
|
|
|
|
"GetLiveFilesChecksumInfo() to verify if it returns "
|
|
|
|
"OK or violate any internal assertion. If N == 0, do not call the "
|
|
|
|
"interface.");
|
|
|
|
|
|
|
|
DEFINE_int32(
|
|
|
|
get_all_column_family_metadata_one_in, 1000000,
|
|
|
|
"With a chance of 1/N, call GetAllColumnFamilyMetaData to verify if it "
|
|
|
|
"violates any internal assertion. If N == 0, do not call the interface.");
|
2020-03-19 00:11:06 +00:00
|
|
|
|
|
|
|
DEFINE_int32(
|
|
|
|
get_sorted_wal_files_one_in, 1000000,
|
|
|
|
"With a chance of 1/N, call GetSortedWalFiles to verify if it returns "
|
|
|
|
"correctly. (Note that this API may legitimately return an error.) If N == "
|
|
|
|
"0, do not call the interface.");
|
|
|
|
|
|
|
|
DEFINE_int32(
|
|
|
|
get_current_wal_file_one_in, 1000000,
|
|
|
|
"With a chance of 1/N, call GetCurrentWalFile to verify if it returns "
|
|
|
|
"correctly. (Note that this API may legitimately return an error.) If N == "
|
|
|
|
"0, do not call the interface.");
|
2019-12-20 20:05:48 +00:00
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_int32(set_options_one_in, 0,
|
|
|
|
"With a chance of 1/N, change some random options");
|
|
|
|
|
|
|
|
DEFINE_int32(set_in_place_one_in, 0,
|
|
|
|
"With a chance of 1/N, toggle in place support option");
|
|
|
|
|
|
|
|
DEFINE_int64(cache_size, 2LL * KB * KB * KB,
|
|
|
|
"Number of bytes to use as a cache of uncompressed data.");
|
|
|
|
|
2021-06-28 06:53:47 +00:00
|
|
|
DEFINE_int32(cache_numshardbits, 6,
|
|
|
|
"Number of shards for the block cache"
|
|
|
|
" is 2 ** cache_numshardbits. Negative means use default settings."
|
2022-06-22 23:04:03 +00:00
|
|
|
" This is applied only if FLAGS_cache_size is greater than 0.");
|
2021-06-28 06:53:47 +00:00
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_bool(cache_index_and_filter_blocks, false,
|
|
|
|
"True if indexes/filters should be cached in block cache.");
|
|
|
|
|
2022-05-17 22:01:51 +00:00
|
|
|
DEFINE_bool(charge_compression_dictionary_building_buffer, false,
|
|
|
|
"Setting for "
|
2022-07-19 06:26:57 +00:00
|
|
|
"CacheEntryRoleOptions::charged of "
|
2022-05-17 22:01:51 +00:00
|
|
|
"CacheEntryRole::kCompressionDictionaryBuildingBuffer");
|
|
|
|
|
|
|
|
DEFINE_bool(charge_filter_construction, false,
|
|
|
|
"Setting for "
|
2022-07-19 06:26:57 +00:00
|
|
|
"CacheEntryRoleOptions::charged of "
|
2022-05-17 22:01:51 +00:00
|
|
|
"CacheEntryRole::kFilterConstruction");
|
|
|
|
|
|
|
|
DEFINE_bool(charge_table_reader, false,
|
|
|
|
"Setting for "
|
2022-07-19 06:26:57 +00:00
|
|
|
"CacheEntryRoleOptions::charged of "
|
2022-05-17 22:01:51 +00:00
|
|
|
"CacheEntryRole::kBlockBasedTableReader");
|
2022-04-06 17:33:00 +00:00
|
|
|
|
Account memory of FileMetaData in global memory limit (#9924)
Summary:
**Context/Summary:**
As revealed by heap profiling, allocation of `FileMetaData` for [newly created file added to a Version](https://github.com/facebook/rocksdb/pull/9924/files#diff-a6aa385940793f95a2c5b39cc670bd440c4547fa54fd44622f756382d5e47e43R774) can consume significant heap memory. This PR is to account that toward our global memory limit based on block cache capacity.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9924
Test Plan:
- Previous `make check` verified there are only 2 places where the memory of the allocated `FileMetaData` can be released
- New unit test `TEST_P(ChargeFileMetadataTestWithParam, Basic)`
- db bench (CPU cost of `charge_file_metadata` in write and compact)
- **write micros/op: -0.24%** : `TEST_TMPDIR=/dev/shm/testdb ./db_bench -benchmarks=fillseq -db=$TEST_TMPDIR -charge_file_metadata=1 (remove this option for pre-PR) -disable_auto_compactions=1 -write_buffer_size=100000 -num=4000000 | egrep 'fillseq'`
- **compact micros/op -0.87%** : `TEST_TMPDIR=/dev/shm/testdb ./db_bench -benchmarks=fillseq -db=$TEST_TMPDIR -charge_file_metadata=1 -disable_auto_compactions=1 -write_buffer_size=100000 -num=4000000 -numdistinct=1000 && ./db_bench -benchmarks=compact -db=$TEST_TMPDIR -use_existing_db=1 -charge_file_metadata=1 -disable_auto_compactions=1 | egrep 'compact'`
table 1 - write
#-run | (pre-PR) avg micros/op | std micros/op | (post-PR) micros/op | std micros/op | change (%)
-- | -- | -- | -- | -- | --
10 | 3.9711 | 0.264408 | 3.9914 | 0.254563 | 0.5111933721
20 | 3.83905 | 0.0664488 | 3.8251 | 0.0695456 | -0.3633711465
40 | 3.86625 | 0.136669 | 3.8867 | 0.143765 | 0.5289363078
80 | 3.87828 | 0.119007 | 3.86791 | 0.115674 | **-0.2673865734**
160 | 3.87677 | 0.162231 | 3.86739 | 0.16663 | **-0.2419539978**
table 2 - compact
#-run | (pre-PR) avg micros/op | std micros/op | (post-PR) micros/op | std micros/op | change (%)
-- | -- | -- | -- | -- | --
10 | 2,399,650.00 | 96,375.80 | 2,359,537.00 | 53,243.60 | -1.67
20 | 2,410,480.00 | 89,988.00 | 2,433,580.00 | 91,121.20 | 0.96
40 | 2.41E+06 | 121811 | 2.39E+06 | 131525 | **-0.96**
80 | 2.40E+06 | 134503 | 2.39E+06 | 108799 | **-0.78**
- stress test: `python3 tools/db_crashtest.py blackbox --charge_file_metadata=1 --cache_size=1` killed as normal
Reviewed By: ajkr
Differential Revision: D36055583
Pulled By: hx235
fbshipit-source-id: b60eab94707103cb1322cf815f05810ef0232625
2022-06-14 20:06:40 +00:00
|
|
|
DEFINE_bool(charge_file_metadata, false,
|
|
|
|
"Setting for "
|
2022-07-19 06:26:57 +00:00
|
|
|
"CacheEntryRoleOptions::charged of "
|
Account memory of FileMetaData in global memory limit (#9924)
Summary:
**Context/Summary:**
As revealed by heap profiling, allocation of `FileMetaData` for [newly created file added to a Version](https://github.com/facebook/rocksdb/pull/9924/files#diff-a6aa385940793f95a2c5b39cc670bd440c4547fa54fd44622f756382d5e47e43R774) can consume significant heap memory. This PR is to account that toward our global memory limit based on block cache capacity.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9924
Test Plan:
- Previous `make check` verified there are only 2 places where the memory of the allocated `FileMetaData` can be released
- New unit test `TEST_P(ChargeFileMetadataTestWithParam, Basic)`
- db bench (CPU cost of `charge_file_metadata` in write and compact)
- **write micros/op: -0.24%** : `TEST_TMPDIR=/dev/shm/testdb ./db_bench -benchmarks=fillseq -db=$TEST_TMPDIR -charge_file_metadata=1 (remove this option for pre-PR) -disable_auto_compactions=1 -write_buffer_size=100000 -num=4000000 | egrep 'fillseq'`
- **compact micros/op -0.87%** : `TEST_TMPDIR=/dev/shm/testdb ./db_bench -benchmarks=fillseq -db=$TEST_TMPDIR -charge_file_metadata=1 -disable_auto_compactions=1 -write_buffer_size=100000 -num=4000000 -numdistinct=1000 && ./db_bench -benchmarks=compact -db=$TEST_TMPDIR -use_existing_db=1 -charge_file_metadata=1 -disable_auto_compactions=1 | egrep 'compact'`
table 1 - write
#-run | (pre-PR) avg micros/op | std micros/op | (post-PR) micros/op | std micros/op | change (%)
-- | -- | -- | -- | -- | --
10 | 3.9711 | 0.264408 | 3.9914 | 0.254563 | 0.5111933721
20 | 3.83905 | 0.0664488 | 3.8251 | 0.0695456 | -0.3633711465
40 | 3.86625 | 0.136669 | 3.8867 | 0.143765 | 0.5289363078
80 | 3.87828 | 0.119007 | 3.86791 | 0.115674 | **-0.2673865734**
160 | 3.87677 | 0.162231 | 3.86739 | 0.16663 | **-0.2419539978**
table 2 - compact
#-run | (pre-PR) avg micros/op | std micros/op | (post-PR) micros/op | std micros/op | change (%)
-- | -- | -- | -- | -- | --
10 | 2,399,650.00 | 96,375.80 | 2,359,537.00 | 53,243.60 | -1.67
20 | 2,410,480.00 | 89,988.00 | 2,433,580.00 | 91,121.20 | 0.96
40 | 2.41E+06 | 121811 | 2.39E+06 | 131525 | **-0.96**
80 | 2.40E+06 | 134503 | 2.39E+06 | 108799 | **-0.78**
- stress test: `python3 tools/db_crashtest.py blackbox --charge_file_metadata=1 --cache_size=1` killed as normal
Reviewed By: ajkr
Differential Revision: D36055583
Pulled By: hx235
fbshipit-source-id: b60eab94707103cb1322cf815f05810ef0232625
2022-06-14 20:06:40 +00:00
|
|
|
"kFileMetadata");
|
|
|
|
|
2022-07-19 06:26:57 +00:00
|
|
|
DEFINE_bool(charge_blob_cache, false,
|
|
|
|
"Setting for "
|
|
|
|
"CacheEntryRoleOptions::charged of "
|
|
|
|
"kBlobCache");
|
|
|
|
|
Option to decouple index and filter partitions (#12939)
Summary:
Partitioned metadata blocks were introduced back in 2017 to deal more gracefully with large DBs where RAM is relatively scarce and some data might be much colder than other data. The feature allows metadata blocks to compete for memory in the block cache against data blocks while alleviating tail latencies and thrash conditions that can arise with large metadata blocks (sometimes megabytes each) that can arise with large SST files. In general, the cost to partitioned metadata is more CPU in accesses (especially for filters where more binary search is needed before hashing can be used) and a bit more memory fragmentation and related overheads.
However the feature has always had a subtle limitation with a subtle effect on performance: index partitions and filter partitions must be cut at the same time, regardless of which wins the space race (hahaha) to metadata_block_size. Commonly filters will be a few times larger than indexes, so index partitions will be under-sized compared to filter (and data) blocks. While this does affect fragmentation and related overheads a bit, I suspect the bigger impact on performance is in the block cache. The coupling of the partition cuts would be defensible if the binary search done to find the filter block was used (on filter hit) to short-circuit binary search to an index partition, but that optimization has not been developed.
Consider two metadata blocks, an under-sized one and a normal-sized one, covering proportional sections of the key space with the same density of read queries. The under-sized one will be more prone to eviction from block cache because it is used less often. This is unfair because of its despite its proportionally smaller cost of keeping in block cache, and most of the cost of a miss to re-load it (random IO) is not proportional to the size (similar latency etc. up to ~32KB).
## This change
Adds a new table option decouple_partitioned_filters allows filter blocks and index blocks to be cut independently. To make this work, the partitioned filter block builder needs to know about the previous key, to generate an appropriate separator for the partition index. In most cases, BlockBasedTableBuilder already has easy access to the previous key to provide to the filter block builder.
This change includes refactoring to pass that previous key to the filter builder when available, with the filter building caching the previous key itself when unavailable, such as during compression dictionary training and some unit tests. Access to the previous key eliminates the need to track the previous prefix, which results in a small SST construction CPU win in prefix filtering cases, regardless of coupling, and possibly a small regression for some non-prefix cases, regardless of coupling, but still overall improvement especially with https://github.com/facebook/rocksdb/issues/12931.
Suggested follow-up:
* Update confusing use of "last key" to refer to "previous key"
* Expand unit test coverage with parallel compression and dictionary training
* Consider an option or enhancement to alleviate under-sized metadata blocks "at the end" of an SST file due to no coordination or awareness of when files are cut.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12939
Test Plan:
unit tests updated. Also did some unit test runs with "hard wired" usage of parallel compression and dictionary training code paths to ensure they were working. Also ran blackbox_crash_test for a while with the new feature.
## SST write performance (CPU)
Using the same testing setup as in https://github.com/facebook/rocksdb/issues/12931 but with -decouple_partitioned_filters=1 in the "after" configuration, which benchmarking shows makes almost no difference in terms of SST write CPU. "After" vs. "before" this PR
```
-partition_index_and_filters=0 -prefix_size=0 -whole_key_filtering=1
923691 vs. 924851 (-0.13%)
-partition_index_and_filters=0 -prefix_size=8 -whole_key_filtering=0
921398 vs. 922973 (-0.17%)
-partition_index_and_filters=0 -prefix_size=8 -whole_key_filtering=1
902259 vs. 908756 (-0.71%)
-partition_index_and_filters=1 -prefix_size=8 -whole_key_filtering=0
917932 vs. 916901 (+0.60%)
-partition_index_and_filters=1 -prefix_size=8 -whole_key_filtering=0
912755 vs. 907298 (+0.60%)
-partition_index_and_filters=1 -prefix_size=8 -whole_key_filtering=1
899754 vs. 892433 (+0.82%)
```
I think this is a pretty good trade, especially in attracting more movement toward partitioned configurations.
## Read performance
Let's see how decoupling affects read performance across various degrees of memory constraint. To simplify LSM structure, we're using FIFO compaction. Since decoupling will overall increase metadata block size, we control for this somewhat with an extra "before" configuration with larger metadata block size setting (8k instead of 4k). Basic setup:
```
(for CS in 0300 1200; do TEST_TMPDIR=/dev/shm/rocksdb1 ./db_bench -benchmarks=fillrandom,flush,readrandom,block_cache_entry_stats -num=5000000 -duration=30 -disable_wal=1 -write_buffer_size=30000000 -bloom_bits=10 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=0 -partition_index_and_filters=1 -statistics=1 -cache_size=${CS}000000 -metadata_block_size=4096 -decouple_partitioned_filters=1 2>&1 | tee results-$CS; done)
```
And read ops/s results:
```CSV
Cache size MB,After/decoupled/4k,Before/4k,Before/8k
3,15593,15158,12826
6,16295,16693,14134
10,20427,20813,18459
20,27035,26836,27384
30,33250,31810,33846
60,35518,32585,35329
100,36612,31805,35292
300,35780,31492,35481
1000,34145,31551,35411
1100,35219,31380,34302
1200,35060,31037,34322
```
If you graph this with log scale on the X axis (internal link: https://pxl.cl/5qKRc), you see that the decoupled/4k configuration is essentially the best of both the before/4k and before/8k configurations: handles really tight memory closer to the old 4k configuration and handles generous memory closer to the old 8k configuration.
Reviewed By: jowlyzhang
Differential Revision: D61376772
Pulled By: pdillinger
fbshipit-source-id: fc2af2aee44290e2d9620f79651a30640799e01f
2024-08-16 22:34:31 +00:00
|
|
|
DEFINE_bool(
|
|
|
|
decouple_partitioned_filters,
|
|
|
|
ROCKSDB_NAMESPACE::BlockBasedTableOptions().decouple_partitioned_filters,
|
|
|
|
"Decouple filter partitioning from index partitioning.");
|
|
|
|
|
2020-10-11 21:52:49 +00:00
|
|
|
DEFINE_int32(
|
|
|
|
top_level_index_pinning,
|
|
|
|
static_cast<int32_t>(ROCKSDB_NAMESPACE::PinningTier::kFallback),
|
|
|
|
"Type of pinning for top-level indexes into metadata partitions (see "
|
|
|
|
"`enum PinningTier` in table.h)");
|
|
|
|
|
|
|
|
DEFINE_int32(
|
|
|
|
partition_pinning,
|
|
|
|
static_cast<int32_t>(ROCKSDB_NAMESPACE::PinningTier::kFallback),
|
|
|
|
"Type of pinning for metadata partitions (see `enum PinningTier` in "
|
|
|
|
"table.h)");
|
|
|
|
|
|
|
|
DEFINE_int32(
|
|
|
|
unpartitioned_pinning,
|
|
|
|
static_cast<int32_t>(ROCKSDB_NAMESPACE::PinningTier::kFallback),
|
|
|
|
"Type of pinning for unpartitioned metadata blocks (see `enum PinningTier` "
|
|
|
|
"in table.h)");
|
|
|
|
|
2022-06-02 01:00:28 +00:00
|
|
|
DEFINE_string(cache_type, "lru_cache", "Type of block cache.");
|
2019-12-09 07:49:32 +00:00
|
|
|
|
|
|
|
DEFINE_uint64(subcompactions, 1,
|
|
|
|
"Maximum number of subcompactions to divide L0-L1 compactions "
|
|
|
|
"into.");
|
|
|
|
|
|
|
|
DEFINE_uint64(periodic_compaction_seconds, 1000,
|
|
|
|
"Files older than this value will be picked up for compaction.");
|
2024-04-16 19:44:44 +00:00
|
|
|
DEFINE_string(daily_offpeak_time_utc, "",
|
|
|
|
"If set, process periodic compactions during this period only");
|
2019-12-09 07:49:32 +00:00
|
|
|
|
|
|
|
DEFINE_uint64(compaction_ttl, 1000,
|
|
|
|
"Files older than TTL will be compacted to the next level.");
|
|
|
|
|
2023-01-03 19:54:58 +00:00
|
|
|
DEFINE_bool(fifo_allow_compaction, false,
|
|
|
|
"If true, set `Options::compaction_options_fifo.allow_compaction = "
|
|
|
|
"true`. It only take effect when FIFO compaction is used.");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_bool(allow_concurrent_memtable_write, false,
|
|
|
|
"Allow multi-writers to update mem tables in parallel.");
|
|
|
|
|
2021-08-11 01:07:48 +00:00
|
|
|
DEFINE_double(experimental_mempurge_threshold, 0.0,
|
|
|
|
"Maximum estimated useful payload that triggers a "
|
|
|
|
"mempurge process to collect memtable garbage bytes.");
|
2021-07-28 20:27:10 +00:00
|
|
|
|
Add missing db crash options (#12414)
Summary:
**Context/Summary:**
We are doing a sweep in all public options, including but not limited to the `Options`, `Read/WriteOptions`, `IngestExternalFileOptions`, cache options.., to find and add the uncovered ones into db crash. The options included in this PR require minimum changes to db crash other than adding the options themselves.
A bonus change: to surface new issues by improved coverage in stderror, we decided to fail/terminate crash test for manual compactions (CompactFiles, CompactRange()) on meaningful errors. See https://github.com/facebook/rocksdb/pull/12414/files#diff-5c4ced6afb6a90e27fec18ab03b2cd89e8f99db87791b4ecc6fa2694284d50c0R2528-R2532, https://github.com/facebook/rocksdb/pull/12414/files#diff-5c4ced6afb6a90e27fec18ab03b2cd89e8f99db87791b4ecc6fa2694284d50c0R2330-R2336 for more.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12414
Test Plan:
- Run `python3 ./tools/db_crashtest.py --simple blackbox` for 10 minutes to ensure no trivial failure
- Run `python3 tools/db_crashtest.py --simple blackbox --compact_files_one_in=1 --compact_range_one_in=1 --read_fault_one_in=1 --write_fault_one_in=1 --interval=50` for a while to ensure the bonus change does not result in trivial crash/termination of stress test
Reviewed By: ajkr, jowlyzhang, cbi42
Differential Revision: D54691774
Pulled By: hx235
fbshipit-source-id: 50443dfb6aaabd8e24c79a2e42b68c6de877be88
2024-03-13 00:24:12 +00:00
|
|
|
DEFINE_bool(enable_write_thread_adaptive_yield,
|
|
|
|
ROCKSDB_NAMESPACE::Options().enable_write_thread_adaptive_yield,
|
2019-12-09 07:49:32 +00:00
|
|
|
"Use a yielding spin loop for brief writer thread waits.");
|
|
|
|
|
2021-02-02 19:39:20 +00:00
|
|
|
// Options for StackableDB-based BlobDB
|
|
|
|
DEFINE_bool(use_blob_db, false, "[Stacked BlobDB] Use BlobDB.");
|
2019-12-20 18:25:48 +00:00
|
|
|
|
2021-02-02 19:39:20 +00:00
|
|
|
DEFINE_uint64(
|
|
|
|
blob_db_min_blob_size,
|
|
|
|
ROCKSDB_NAMESPACE::blob_db::BlobDBOptions().min_blob_size,
|
|
|
|
"[Stacked BlobDB] Smallest blob to store in a file. Blobs "
|
|
|
|
"smaller than this will be inlined with the key in the LSM tree.");
|
2019-12-20 18:25:48 +00:00
|
|
|
|
2021-02-02 19:39:20 +00:00
|
|
|
DEFINE_uint64(
|
|
|
|
blob_db_bytes_per_sync,
|
|
|
|
ROCKSDB_NAMESPACE::blob_db::BlobDBOptions().bytes_per_sync,
|
|
|
|
"[Stacked BlobDB] Sync blob files once per every N bytes written.");
|
2019-12-20 18:25:48 +00:00
|
|
|
|
|
|
|
DEFINE_uint64(blob_db_file_size,
|
2020-02-20 20:07:53 +00:00
|
|
|
ROCKSDB_NAMESPACE::blob_db::BlobDBOptions().blob_file_size,
|
2021-02-02 19:39:20 +00:00
|
|
|
"[Stacked BlobDB] Target size of each blob file.");
|
2019-12-20 18:25:48 +00:00
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
DEFINE_bool(
|
|
|
|
blob_db_enable_gc,
|
|
|
|
ROCKSDB_NAMESPACE::blob_db::BlobDBOptions().enable_garbage_collection,
|
2021-02-02 19:39:20 +00:00
|
|
|
"[Stacked BlobDB] Enable BlobDB garbage collection.");
|
2019-12-20 18:25:48 +00:00
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
DEFINE_double(
|
|
|
|
blob_db_gc_cutoff,
|
|
|
|
ROCKSDB_NAMESPACE::blob_db::BlobDBOptions().garbage_collection_cutoff,
|
2021-02-02 19:39:20 +00:00
|
|
|
"[Stacked BlobDB] Cutoff ratio for BlobDB garbage collection.");
|
|
|
|
|
|
|
|
// Options for integrated BlobDB
|
|
|
|
DEFINE_bool(allow_setting_blob_options_dynamically, false,
|
|
|
|
"[Integrated BlobDB] Allow setting blob options dynamically.");
|
|
|
|
|
|
|
|
DEFINE_bool(
|
|
|
|
enable_blob_files,
|
|
|
|
ROCKSDB_NAMESPACE::AdvancedColumnFamilyOptions().enable_blob_files,
|
|
|
|
"[Integrated BlobDB] Enable writing large values to separate blob files.");
|
|
|
|
|
|
|
|
DEFINE_uint64(min_blob_size,
|
|
|
|
ROCKSDB_NAMESPACE::AdvancedColumnFamilyOptions().min_blob_size,
|
|
|
|
"[Integrated BlobDB] The size of the smallest value to be stored "
|
|
|
|
"separately in a blob file.");
|
|
|
|
|
|
|
|
DEFINE_uint64(blob_file_size,
|
|
|
|
ROCKSDB_NAMESPACE::AdvancedColumnFamilyOptions().blob_file_size,
|
|
|
|
"[Integrated BlobDB] The size limit for blob files.");
|
|
|
|
|
|
|
|
DEFINE_string(blob_compression_type, "none",
|
|
|
|
"[Integrated BlobDB] The compression algorithm to use for large "
|
|
|
|
"values stored in blob files.");
|
|
|
|
|
|
|
|
DEFINE_bool(enable_blob_garbage_collection,
|
|
|
|
ROCKSDB_NAMESPACE::AdvancedColumnFamilyOptions()
|
|
|
|
.enable_blob_garbage_collection,
|
|
|
|
"[Integrated BlobDB] Enable blob garbage collection.");
|
|
|
|
|
|
|
|
DEFINE_double(blob_garbage_collection_age_cutoff,
|
|
|
|
ROCKSDB_NAMESPACE::AdvancedColumnFamilyOptions()
|
|
|
|
.blob_garbage_collection_age_cutoff,
|
|
|
|
"[Integrated BlobDB] The cutoff in terms of blob file age for "
|
|
|
|
"garbage collection.");
|
2019-12-20 18:25:48 +00:00
|
|
|
|
Make it possible to force the garbage collection of the oldest blob files (#8994)
Summary:
The current BlobDB garbage collection logic works by relocating the valid
blobs from the oldest blob files as they are encountered during compaction,
and cleaning up blob files once they contain nothing but garbage. However,
with sufficiently skewed workloads, it is theoretically possible to end up in a
situation when few or no compactions get scheduled for the SST files that contain
references to the oldest blob files, which can lead to increased space amp due
to the lack of GC.
In order to efficiently handle such workloads, the patch adds a new BlobDB
configuration option called `blob_garbage_collection_force_threshold`,
which signals to BlobDB to schedule targeted compactions for the SST files
that keep alive the oldest batch of blob files if the overall ratio of garbage in
the given blob files meets the threshold *and* all the given blob files are
eligible for GC based on `blob_garbage_collection_age_cutoff`. (For example,
if the new option is set to 0.9, targeted compactions will get scheduled if the
sum of garbage bytes meets or exceeds 90% of the sum of total bytes in the
oldest blob files, assuming all affected blob files are below the age-based cutoff.)
The net result of these targeted compactions is that the valid blobs in the oldest
blob files are relocated and the oldest blob files themselves cleaned up (since
*all* SST files that rely on them get compacted away).
These targeted compactions are similar to periodic compactions in the sense
that they force certain SST files that otherwise would not get picked up to undergo
compaction and also in the sense that instead of merging files from multiple levels,
they target a single file. (Note: such compactions might still include neighboring files
from the same level due to the need of having a "clean cut" boundary but they never
include any files from any other level.)
This functionality is currently only supported with the leveled compaction style
and is inactive by default (since the default value is set to 1.0, i.e. 100%).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/8994
Test Plan: Ran `make check` and tested using `db_bench` and the stress/crash tests.
Reviewed By: riversand963
Differential Revision: D31489850
Pulled By: ltamasi
fbshipit-source-id: 44057d511726a0e2a03c5d9313d7511b3f0c4eab
2021-10-12 01:00:44 +00:00
|
|
|
DEFINE_double(blob_garbage_collection_force_threshold,
|
|
|
|
ROCKSDB_NAMESPACE::AdvancedColumnFamilyOptions()
|
|
|
|
.blob_garbage_collection_force_threshold,
|
|
|
|
"[Integrated BlobDB] The threshold for the ratio of garbage in "
|
2024-09-19 22:47:13 +00:00
|
|
|
"the eligible blob files for forcing garbage collection.");
|
Make it possible to force the garbage collection of the oldest blob files (#8994)
Summary:
The current BlobDB garbage collection logic works by relocating the valid
blobs from the oldest blob files as they are encountered during compaction,
and cleaning up blob files once they contain nothing but garbage. However,
with sufficiently skewed workloads, it is theoretically possible to end up in a
situation when few or no compactions get scheduled for the SST files that contain
references to the oldest blob files, which can lead to increased space amp due
to the lack of GC.
In order to efficiently handle such workloads, the patch adds a new BlobDB
configuration option called `blob_garbage_collection_force_threshold`,
which signals to BlobDB to schedule targeted compactions for the SST files
that keep alive the oldest batch of blob files if the overall ratio of garbage in
the given blob files meets the threshold *and* all the given blob files are
eligible for GC based on `blob_garbage_collection_age_cutoff`. (For example,
if the new option is set to 0.9, targeted compactions will get scheduled if the
sum of garbage bytes meets or exceeds 90% of the sum of total bytes in the
oldest blob files, assuming all affected blob files are below the age-based cutoff.)
The net result of these targeted compactions is that the valid blobs in the oldest
blob files are relocated and the oldest blob files themselves cleaned up (since
*all* SST files that rely on them get compacted away).
These targeted compactions are similar to periodic compactions in the sense
that they force certain SST files that otherwise would not get picked up to undergo
compaction and also in the sense that instead of merging files from multiple levels,
they target a single file. (Note: such compactions might still include neighboring files
from the same level due to the need of having a "clean cut" boundary but they never
include any files from any other level.)
This functionality is currently only supported with the leveled compaction style
and is inactive by default (since the default value is set to 1.0, i.e. 100%).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/8994
Test Plan: Ran `make check` and tested using `db_bench` and the stress/crash tests.
Reviewed By: riversand963
Differential Revision: D31489850
Pulled By: ltamasi
fbshipit-source-id: 44057d511726a0e2a03c5d9313d7511b3f0c4eab
2021-10-12 01:00:44 +00:00
|
|
|
|
2021-11-20 01:52:42 +00:00
|
|
|
DEFINE_uint64(blob_compaction_readahead_size,
|
|
|
|
ROCKSDB_NAMESPACE::AdvancedColumnFamilyOptions()
|
|
|
|
.blob_compaction_readahead_size,
|
|
|
|
"[Integrated BlobDB] Compaction readahead for blob files.");
|
|
|
|
|
2022-06-03 03:04:33 +00:00
|
|
|
DEFINE_int32(
|
|
|
|
blob_file_starting_level,
|
|
|
|
ROCKSDB_NAMESPACE::AdvancedColumnFamilyOptions().blob_file_starting_level,
|
|
|
|
"[Integrated BlobDB] Enable writing blob files during flushes and "
|
|
|
|
"compactions starting from the specified level.");
|
|
|
|
|
2022-06-22 23:04:03 +00:00
|
|
|
DEFINE_bool(use_blob_cache, false, "[Integrated BlobDB] Enable blob cache.");
|
|
|
|
|
|
|
|
DEFINE_bool(
|
|
|
|
use_shared_block_and_blob_cache, true,
|
|
|
|
"[Integrated BlobDB] Use a shared backing cache for both block "
|
|
|
|
"cache and blob cache. It only takes effect if use_blob_cache is enabled.");
|
|
|
|
|
|
|
|
DEFINE_uint64(
|
|
|
|
blob_cache_size, 2LL * KB * KB * KB,
|
|
|
|
"[Integrated BlobDB] Number of bytes to use as a cache of blobs. It only "
|
|
|
|
"takes effect if the block and blob caches are different "
|
|
|
|
"(use_shared_block_and_blob_cache = false).");
|
|
|
|
|
|
|
|
DEFINE_int32(blob_cache_numshardbits, 6,
|
|
|
|
"[Integrated BlobDB] Number of shards for the blob cache is 2 ** "
|
|
|
|
"blob_cache_numshardbits. Negative means use default settings. "
|
|
|
|
"It only takes effect if blob_cache_size is greater than 0, and "
|
|
|
|
"the block and blob caches are different "
|
|
|
|
"(use_shared_block_and_blob_cache = false).");
|
|
|
|
|
2022-07-17 14:13:59 +00:00
|
|
|
DEFINE_int32(prepopulate_blob_cache, 0,
|
|
|
|
"[Integrated BlobDB] Pre-populate hot/warm blobs in blob cache. 0 "
|
|
|
|
"to disable and 1 to insert during flush.");
|
|
|
|
|
2022-08-08 20:08:35 +00:00
|
|
|
DEFINE_int64(preclude_last_level_data_seconds, 0,
|
|
|
|
"Preclude data from the last level. Used with tiered storage "
|
|
|
|
"feature to preclude new data from comacting to the last level.");
|
|
|
|
|
2022-10-16 16:28:43 +00:00
|
|
|
DEFINE_int64(
|
|
|
|
preserve_internal_time_seconds, 0,
|
|
|
|
"Preserve internal time information which is attached to each SST.");
|
|
|
|
|
2024-04-30 22:40:35 +00:00
|
|
|
DEFINE_uint32(use_timed_put_one_in, 0,
|
|
|
|
"If greater than zero, TimedPut is used per every N write ops on "
|
|
|
|
"on average.");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
static const bool FLAGS_subcompactions_dummy __attribute__((__unused__)) =
|
|
|
|
RegisterFlagValidator(&FLAGS_subcompactions, &ValidateUint32Range);
|
|
|
|
|
|
|
|
static bool ValidateInt32Positive(const char* flagname, int32_t value) {
|
|
|
|
if (value < 0) {
|
|
|
|
fprintf(stderr, "Invalid value for --%s: %d, must be >=0\n", flagname,
|
|
|
|
value);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
DEFINE_int32(reopen, 10, "Number of times database reopens");
|
|
|
|
static const bool FLAGS_reopen_dummy __attribute__((__unused__)) =
|
|
|
|
RegisterFlagValidator(&FLAGS_reopen, &ValidateInt32Positive);
|
|
|
|
|
2019-12-10 16:38:23 +00:00
|
|
|
DEFINE_double(bloom_bits, 10,
|
|
|
|
"Bloom filter bits per key. "
|
|
|
|
"Negative means use default settings.");
|
2019-12-09 07:49:32 +00:00
|
|
|
|
Add Bloom/Ribbon hybrid API support (#8679)
Summary:
This is essentially resurrection and fixing of the part of
https://github.com/facebook/rocksdb/issues/8198 that was reverted in https://github.com/facebook/rocksdb/issues/8212, using data added in https://github.com/facebook/rocksdb/issues/8246. Basically,
when configuring Ribbon filter, you can specify an LSM level before which
Bloom will be used instead of Ribbon. But Bloom is only considered for
Leveled and Universal compaction styles and file going into a known LSM
level. This way, SST file writer, FIFO compaction, etc. use Ribbon filter as
you would expect with NewRibbonFilterPolicy.
So that this can be controlled with a single int value and so that flushes
can be distinguished from intra-L0, we consider flush to go to level -1 for
the purposes of this option. (Explained in API comment.)
I also expect the most common and recommended Ribbon configuration to
use Bloom during flush, to minimize slowing down writes and because according
to my estimates, Ribbon only pays off if the structure lives in memory for
more than an hour. Thus, I have changed the default for NewRibbonFilterPolicy
to be this mild hybrid configuration. I don't really want to add something like
NewHybridFilterPolicy because at least the mild hybrid configuration (Bloom for
flush, Ribbon otherwise) should be considered a natural choice.
C APIs also updated, but because they don't support overloading,
rocksdb_filterpolicy_create_ribbon is kept pure ribbon for clarity and
rocksdb_filterpolicy_create_ribbon_hybrid must be called for a hybrid
configuration. While touching C API, I changed bits per key options from
int to double.
BuiltinFilterPolicy is needed so that LevelThresholdFilterPolicy doesn't inherit
unused fields from BloomFilterPolicy.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/8679
Test Plan: new + updated tests, including crash test
Reviewed By: jay-zhuang
Differential Revision: D30445797
Pulled By: pdillinger
fbshipit-source-id: 6f5aeddfd6d79f7e55493b563c2d1d2d568892e1
2021-08-21 00:59:24 +00:00
|
|
|
DEFINE_int32(
|
2023-09-15 22:46:10 +00:00
|
|
|
bloom_before_level, 999,
|
Add Bloom/Ribbon hybrid API support (#8679)
Summary:
This is essentially resurrection and fixing of the part of
https://github.com/facebook/rocksdb/issues/8198 that was reverted in https://github.com/facebook/rocksdb/issues/8212, using data added in https://github.com/facebook/rocksdb/issues/8246. Basically,
when configuring Ribbon filter, you can specify an LSM level before which
Bloom will be used instead of Ribbon. But Bloom is only considered for
Leveled and Universal compaction styles and file going into a known LSM
level. This way, SST file writer, FIFO compaction, etc. use Ribbon filter as
you would expect with NewRibbonFilterPolicy.
So that this can be controlled with a single int value and so that flushes
can be distinguished from intra-L0, we consider flush to go to level -1 for
the purposes of this option. (Explained in API comment.)
I also expect the most common and recommended Ribbon configuration to
use Bloom during flush, to minimize slowing down writes and because according
to my estimates, Ribbon only pays off if the structure lives in memory for
more than an hour. Thus, I have changed the default for NewRibbonFilterPolicy
to be this mild hybrid configuration. I don't really want to add something like
NewHybridFilterPolicy because at least the mild hybrid configuration (Bloom for
flush, Ribbon otherwise) should be considered a natural choice.
C APIs also updated, but because they don't support overloading,
rocksdb_filterpolicy_create_ribbon is kept pure ribbon for clarity and
rocksdb_filterpolicy_create_ribbon_hybrid must be called for a hybrid
configuration. While touching C API, I changed bits per key options from
int to double.
BuiltinFilterPolicy is needed so that LevelThresholdFilterPolicy doesn't inherit
unused fields from BloomFilterPolicy.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/8679
Test Plan: new + updated tests, including crash test
Reviewed By: jay-zhuang
Differential Revision: D30445797
Pulled By: pdillinger
fbshipit-source-id: 6f5aeddfd6d79f7e55493b563c2d1d2d568892e1
2021-08-21 00:59:24 +00:00
|
|
|
"Use Bloom filter on levels below specified and Ribbon beginning on level "
|
2023-09-15 22:46:10 +00:00
|
|
|
"specified. Flush is considered level -1. Setting -1 -> always Ribbon. "
|
|
|
|
"0 -> Ribbon except Bloom for flush. INT_MAX (typically 2147483647) -> "
|
|
|
|
"always Bloom.");
|
Experimental (production candidate) SST schema for Ribbon filter (#7658)
Summary:
Added experimental public API for Ribbon filter:
NewExperimentalRibbonFilterPolicy(). This experimental API will
take a "Bloom equivalent" bits per key, and configure the Ribbon
filter for the same FP rate as Bloom would have but ~30% space
savings. (Note: optimize_filters_for_memory is not yet implemented
for Ribbon filter. That can be added with no effect on schema.)
Internally, the Ribbon filter is configured using a "one_in_fp_rate"
value, which is 1 over desired FP rate. For example, use 100 for 1%
FP rate. I'm expecting this will be used in the future for configuring
Bloom-like filters, as I expect people to more commonly hold constant
the filter accuracy and change the space vs. time trade-off, rather than
hold constant the space (per key) and change the accuracy vs. time
trade-off, though we might make that available.
### Benchmarking
```
$ ./filter_bench -impl=2 -quick -m_keys_total_max=200 -average_keys_per_filter=100000 -net_includes_hashing
Building...
Build avg ns/key: 34.1341
Number of filters: 1993
Total size (MB): 238.488
Reported total allocated memory (MB): 262.875
Reported internal fragmentation: 10.2255%
Bits/key stored: 10.0029
----------------------------
Mixed inside/outside queries...
Single filter net ns/op: 18.7508
Random filter net ns/op: 258.246
Average FP rate %: 0.968672
----------------------------
Done. (For more info, run with -legend or -help.)
$ ./filter_bench -impl=3 -quick -m_keys_total_max=200 -average_keys_per_filter=100000 -net_includes_hashing
Building...
Build avg ns/key: 130.851
Number of filters: 1993
Total size (MB): 168.166
Reported total allocated memory (MB): 183.211
Reported internal fragmentation: 8.94626%
Bits/key stored: 7.05341
----------------------------
Mixed inside/outside queries...
Single filter net ns/op: 58.4523
Random filter net ns/op: 363.717
Average FP rate %: 0.952978
----------------------------
Done. (For more info, run with -legend or -help.)
```
168.166 / 238.488 = 0.705 -> 29.5% space reduction
130.851 / 34.1341 = 3.83x construction time for this Ribbon filter vs. lastest Bloom filter (could make that as little as about 2.5x for less space reduction)
### Working around a hashing "flaw"
bloom_test discovered a flaw in the simple hashing applied in
StandardHasher when num_starts == 1 (num_slots == 128), showing an
excessively high FP rate. The problem is that when many entries, on the
order of number of hash bits or kCoeffBits, are associated with the same
start location, the correlation between the CoeffRow and ResultRow (for
efficiency) can lead to a solution that is "universal," or nearly so, for
entries mapping to that start location. (Normally, variance in start
location breaks the effective association between CoeffRow and
ResultRow; the same value for CoeffRow is effectively different if start
locations are different.) Without kUseSmash and with num_starts > 1 (thus
num_starts ~= num_slots), this flaw should be completely irrelevant. Even
with 10M slots, the chances of a single slot having just 16 (or more)
entries map to it--not enough to cause an FP problem, which would be local
to that slot if it happened--is 1 in millions. This spreadsheet formula
shows that: =1/(10000000*(1 - POISSON(15, 1, TRUE)))
As kUseSmash==false (the setting for Standard128RibbonBitsBuilder) is
intended for CPU efficiency of filters with many more entries/slots than
kCoeffBits, a very reasonable work-around is to disallow num_starts==1
when !kUseSmash, by making the minimum non-zero number of slots
2*kCoeffBits. This is the work-around I've applied. This also means that
the new Ribbon filter schema (Standard128RibbonBitsBuilder) is not
space-efficient for less than a few hundred entries. Because of this, I
have made it fall back on constructing a Bloom filter, under existing
schema, when that is more space efficient for small filters. (We can
change this in the future if we want.)
TODO: better unit tests for this case in ribbon_test, and probably
update StandardHasher for kUseSmash case so that it can scale nicely to
small filters.
### Other related changes
* Add Ribbon filter to stress/crash test
* Add Ribbon filter to filter_bench as -impl=3
* Add option string support, as in "filter_policy=experimental_ribbon:5.678;"
where 5.678 is the Bloom equivalent bits per key.
* Rename internal mode BloomFilterPolicy::kAuto to kAutoBloom
* Add a general BuiltinFilterBitsBuilder::CalculateNumEntry based on
binary searching CalculateSpace (inefficient), so that subclasses
(especially experimental ones) don't have to provide an efficient
implementation inverting CalculateSpace.
* Minor refactor FastLocalBloomBitsBuilder for new base class
XXH3pFilterBitsBuilder shared with new Standard128RibbonBitsBuilder,
which allows the latter to fall back on Bloom construction in some
extreme cases.
* Mostly updated bloom_test for Ribbon filter, though a test like
FullBloomTest::Schema is a next TODO to ensure schema stability
(in case this becomes production-ready schema as it is).
* Add some APIs to ribbon_impl.h for configuring Ribbon filters.
Although these are reasonably covered by bloom_test, TODO more unit
tests in ribbon_test
* Added a "tool" FindOccupancyForSuccessRate to ribbon_test to get data
for constructing the linear approximations in GetNumSlotsFor95PctSuccess.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/7658
Test Plan:
Some unit tests updated but other testing is left TODO. This
is considered experimental but laying down schema compatibility as early
as possible in case it proves production-quality. Also tested in
stress/crash test.
Reviewed By: jay-zhuang
Differential Revision: D24899349
Pulled By: pdillinger
fbshipit-source-id: 9715f3e6371c959d923aea8077c9423c7a9f82b8
2020-11-13 04:45:02 +00:00
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_bool(partition_filters, false,
|
|
|
|
"use partitioned filters "
|
|
|
|
"for block-based table");
|
|
|
|
|
Minimize memory internal fragmentation for Bloom filters (#6427)
Summary:
New experimental option BBTO::optimize_filters_for_memory builds
filters that maximize their use of "usable size" from malloc_usable_size,
which is also used to compute block cache charges.
Rather than always "rounding up," we track state in the
BloomFilterPolicy object to mix essentially "rounding down" and
"rounding up" so that the average FP rate of all generated filters is
the same as without the option. (YMMV as heavily accessed filters might
be unluckily lower accuracy.)
Thus, the option near-minimizes what the block cache considers as
"memory used" for a given target Bloom filter false positive rate and
Bloom filter implementation. There are no forward or backward
compatibility issues with this change, though it only works on the
format_version=5 Bloom filter.
With Jemalloc, we see about 10% reduction in memory footprint (and block
cache charge) for Bloom filters, but 1-2% increase in storage footprint,
due to encoding efficiency losses (FP rate is non-linear with bits/key).
Why not weighted random round up/down rather than state tracking? By
only requiring malloc_usable_size, we don't actually know what the next
larger and next smaller usable sizes for the allocator are. We pick a
requested size, accept and use whatever usable size it has, and use the
difference to inform our next choice. This allows us to narrow in on the
right balance without tracking/predicting usable sizes.
Why not weight history of generated filter false positive rates by
number of keys? This could lead to excess skew in small filters after
generating a large filter.
Results from filter_bench with jemalloc (irrelevant details omitted):
(normal keys/filter, but high variance)
$ ./filter_bench -quick -impl=2 -average_keys_per_filter=30000 -vary_key_count_ratio=0.9
Build avg ns/key: 29.6278
Number of filters: 5516
Total size (MB): 200.046
Reported total allocated memory (MB): 220.597
Reported internal fragmentation: 10.2732%
Bits/key stored: 10.0097
Average FP rate %: 0.965228
$ ./filter_bench -quick -impl=2 -average_keys_per_filter=30000 -vary_key_count_ratio=0.9 -optimize_filters_for_memory
Build avg ns/key: 30.5104
Number of filters: 5464
Total size (MB): 200.015
Reported total allocated memory (MB): 200.322
Reported internal fragmentation: 0.153709%
Bits/key stored: 10.1011
Average FP rate %: 0.966313
(very few keys / filter, optimization not as effective due to ~59 byte
internal fragmentation in blocked Bloom filter representation)
$ ./filter_bench -quick -impl=2 -average_keys_per_filter=1000 -vary_key_count_ratio=0.9
Build avg ns/key: 29.5649
Number of filters: 162950
Total size (MB): 200.001
Reported total allocated memory (MB): 224.624
Reported internal fragmentation: 12.3117%
Bits/key stored: 10.2951
Average FP rate %: 0.821534
$ ./filter_bench -quick -impl=2 -average_keys_per_filter=1000 -vary_key_count_ratio=0.9 -optimize_filters_for_memory
Build avg ns/key: 31.8057
Number of filters: 159849
Total size (MB): 200
Reported total allocated memory (MB): 208.846
Reported internal fragmentation: 4.42297%
Bits/key stored: 10.4948
Average FP rate %: 0.811006
(high keys/filter)
$ ./filter_bench -quick -impl=2 -average_keys_per_filter=1000000 -vary_key_count_ratio=0.9
Build avg ns/key: 29.7017
Number of filters: 164
Total size (MB): 200.352
Reported total allocated memory (MB): 221.5
Reported internal fragmentation: 10.5552%
Bits/key stored: 10.0003
Average FP rate %: 0.969358
$ ./filter_bench -quick -impl=2 -average_keys_per_filter=1000000 -vary_key_count_ratio=0.9 -optimize_filters_for_memory
Build avg ns/key: 30.7131
Number of filters: 160
Total size (MB): 200.928
Reported total allocated memory (MB): 200.938
Reported internal fragmentation: 0.00448054%
Bits/key stored: 10.1852
Average FP rate %: 0.963387
And from db_bench (block cache) with jemalloc:
$ ./db_bench -db=/dev/shm/dbbench.no_optimize -benchmarks=fillrandom -format_version=5 -value_size=90 -bloom_bits=10 -num=2000000 -threads=8 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=false
$ ./db_bench -db=/dev/shm/dbbench -benchmarks=fillrandom -format_version=5 -value_size=90 -bloom_bits=10 -num=2000000 -threads=8 -optimize_filters_for_memory -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=false
$ (for FILE in /dev/shm/dbbench.no_optimize/*.sst; do ./sst_dump --file=$FILE --show_properties | grep 'filter block' ; done) | awk '{ t += $4; } END { print t; }'
17063835
$ (for FILE in /dev/shm/dbbench/*.sst; do ./sst_dump --file=$FILE --show_properties | grep 'filter block' ; done) | awk '{ t += $4; } END { print t; }'
17430747
$ #^ 2.1% additional filter storage
$ ./db_bench -db=/dev/shm/dbbench.no_optimize -use_existing_db -benchmarks=readrandom,stats -statistics -bloom_bits=10 -num=2000000 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=false -duration=10 -cache_index_and_filter_blocks -cache_size=1000000000
rocksdb.block.cache.index.add COUNT : 33
rocksdb.block.cache.index.bytes.insert COUNT : 8440400
rocksdb.block.cache.filter.add COUNT : 33
rocksdb.block.cache.filter.bytes.insert COUNT : 21087528
rocksdb.bloom.filter.useful COUNT : 4963889
rocksdb.bloom.filter.full.positive COUNT : 1214081
rocksdb.bloom.filter.full.true.positive COUNT : 1161999
$ #^ 1.04 % observed FP rate
$ ./db_bench -db=/dev/shm/dbbench -use_existing_db -benchmarks=readrandom,stats -statistics -bloom_bits=10 -num=2000000 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=false -optimize_filters_for_memory -duration=10 -cache_index_and_filter_blocks -cache_size=1000000000
rocksdb.block.cache.index.add COUNT : 33
rocksdb.block.cache.index.bytes.insert COUNT : 8448592
rocksdb.block.cache.filter.add COUNT : 33
rocksdb.block.cache.filter.bytes.insert COUNT : 18220328
rocksdb.bloom.filter.useful COUNT : 5360933
rocksdb.bloom.filter.full.positive COUNT : 1321315
rocksdb.bloom.filter.full.true.positive COUNT : 1262999
$ #^ 1.08 % observed FP rate, 13.6% less memory usage for filters
(Due to specific key density, this example tends to generate filters that are "worse than average" for internal fragmentation. "Better than average" cases can show little or no improvement.)
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6427
Test Plan: unit test added, 'make check' with gcc, clang and valgrind
Reviewed By: siying
Differential Revision: D22124374
Pulled By: pdillinger
fbshipit-source-id: f3e3aa152f9043ddf4fae25799e76341d0d8714e
2020-06-22 20:30:57 +00:00
|
|
|
DEFINE_bool(
|
|
|
|
optimize_filters_for_memory,
|
|
|
|
ROCKSDB_NAMESPACE::BlockBasedTableOptions().optimize_filters_for_memory,
|
|
|
|
"Minimize memory footprint of filters");
|
|
|
|
|
Detect (new) Bloom/Ribbon Filter construction corruption (#9342)
Summary:
Note: rebase on and merge after https://github.com/facebook/rocksdb/pull/9349, https://github.com/facebook/rocksdb/pull/9345, (optional) https://github.com/facebook/rocksdb/pull/9393
**Context:**
(Quoted from pdillinger) Layers of information during new Bloom/Ribbon Filter construction in building block-based tables includes the following:
a) set of keys to add to filter
b) set of hashes to add to filter (64-bit hash applied to each key)
c) set of Bloom indices to set in filter, with duplicates
d) set of Bloom indices to set in filter, deduplicated
e) final filter and its checksum
This PR aims to detect corruption (e.g, unexpected hardware/software corruption on data structures residing in the memory for a long time) from b) to e) and leave a) as future works for application level.
- b)'s corruption is detected by verifying the xor checksum of the hash entries calculated as the entries accumulate before being added to the filter. (i.e, `XXPH3FilterBitsBuilder::MaybeVerifyHashEntriesChecksum()`)
- c) - e)'s corruption is detected by verifying the hash entries indeed exists in the constructed filter by re-querying these hash entries in the filter (i.e, `FilterBitsBuilder::MaybePostVerify()`) after computing the block checksum (except for PartitionFilter, which is done right after each `FilterBitsBuilder::Finish` for impl simplicity - see code comment for more). For this stage of detection, we assume hash entries are not corrupted after checking on b) since the time interval from b) to c) is relatively short IMO.
Option to enable this feature of detection is `BlockBasedTableOptions::detect_filter_construct_corruption` which is false by default.
**Summary:**
- Implemented new functions `XXPH3FilterBitsBuilder::MaybeVerifyHashEntriesChecksum()` and `FilterBitsBuilder::MaybePostVerify()`
- Ensured hash entries, final filter and banding and their [cache reservation ](https://github.com/facebook/rocksdb/issues/9073) are released properly despite corruption
- See [Filter.construction.artifacts.release.point.pdf ](https://github.com/facebook/rocksdb/files/7923487/Design.Filter.construction.artifacts.release.point.pdf) for high-level design
- Bundled and refactored hash entries's related artifact in XXPH3FilterBitsBuilder into `HashEntriesInfo` for better control on lifetime of these artifact during `SwapEntires`, `ResetEntries`
- Ensured RocksDB block-based table builder calls `FilterBitsBuilder::MaybePostVerify()` after constructing the filter by `FilterBitsBuilder::Finish()`
- When encountering such filter construction corruption, stop writing the filter content to files and mark such a block-based table building non-ok by storing the corruption status in the builder.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9342
Test Plan:
- Added new unit test `DBFilterConstructionCorruptionTestWithParam.DetectCorruption`
- Included this new feature in `DBFilterConstructionReserveMemoryTestWithParam.ReserveMemory` as this feature heavily touch ReserveMemory's impl
- For fallback case, I run `./filter_bench -impl=3 -detect_filter_construct_corruption=true -reserve_table_builder_memory=true -strict_capacity_limit=true -quick -runs 10 | grep 'Build avg'` to make sure nothing break.
- Added to `filter_bench`: increased filter construction time by **30%**, mostly by `MaybePostVerify()`
- FastLocalBloom
- Before change: `./filter_bench -impl=2 -quick -runs 10 | grep 'Build avg'`: **28.86643s**
- After change:
- `./filter_bench -impl=2 -detect_filter_construct_corruption=false -quick -runs 10 | grep 'Build avg'` (expect a tiny increase due to MaybePostVerify is always called regardless): **27.6644s (-4% perf improvement might be due to now we don't drop bloom hash entry in `AddAllEntries` along iteration but in bulk later, same with the bypassing-MaybePostVerify case below)**
- `./filter_bench -impl=2 -detect_filter_construct_corruption=true -quick -runs 10 | grep 'Build avg'` (expect acceptable increase): **34.41159s (+20%)**
- `./filter_bench -impl=2 -detect_filter_construct_corruption=true -quick -runs 10 | grep 'Build avg'` (by-passing MaybePostVerify, expect minor increase): **27.13431s (-6%)**
- Standard128Ribbon
- Before change: `./filter_bench -impl=3 -quick -runs 10 | grep 'Build avg'`: **122.5384s**
- After change:
- `./filter_bench -impl=3 -detect_filter_construct_corruption=false -quick -runs 10 | grep 'Build avg'` (expect a tiny increase due to MaybePostVerify is always called regardless - verified by removing MaybePostVerify under this case and found only +-1ns difference): **124.3588s (+2%)**
- `./filter_bench -impl=3 -detect_filter_construct_corruption=true -quick -runs 10 | grep 'Build avg'`(expect acceptable increase): **159.4946s (+30%)**
- `./filter_bench -impl=3 -detect_filter_construct_corruption=true -quick -runs 10 | grep 'Build avg'`(by-passing MaybePostVerify, expect minor increase) : **125.258s (+2%)**
- Added to `db_stress`: `make crash_test`, `./db_stress --detect_filter_construct_corruption=true`
- Manually smoke-tested: manually corrupted the filter construction in some db level tests with basic PUT and background flush. As expected, the error did get returned to users in subsequent PUT and Flush status.
Reviewed By: pdillinger
Differential Revision: D33746928
Pulled By: hx235
fbshipit-source-id: cb056426be5a7debc1cd16f23bc250f36a08ca57
2022-02-02 01:41:20 +00:00
|
|
|
DEFINE_bool(
|
|
|
|
detect_filter_construct_corruption,
|
|
|
|
ROCKSDB_NAMESPACE::BlockBasedTableOptions()
|
|
|
|
.detect_filter_construct_corruption,
|
|
|
|
"Detect corruption during new Bloom Filter and Ribbon Filter construction");
|
|
|
|
|
2024-06-18 23:16:09 +00:00
|
|
|
DEFINE_string(sqfc_name, "foo",
|
|
|
|
"Config name to select from SstQueryFilterConfigsManager.");
|
|
|
|
|
|
|
|
DEFINE_uint32(sqfc_version, 0,
|
|
|
|
"User-defined filtering version to select from "
|
|
|
|
"SstQueryFilterConfigsManager. 0 = disable writing filters");
|
|
|
|
|
|
|
|
DEFINE_bool(use_sqfc_for_range_queries, true,
|
|
|
|
"Apply SstQueryFilters to range queries");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_int32(
|
|
|
|
index_type,
|
2020-02-20 20:07:53 +00:00
|
|
|
static_cast<int32_t>(
|
2022-06-21 23:23:58 +00:00
|
|
|
ROCKSDB_NAMESPACE::BlockBasedTableOptions().index_type),
|
2019-12-09 07:49:32 +00:00
|
|
|
"Type of block-based table index (see `enum IndexType` in table.h)");
|
|
|
|
|
2022-06-21 23:23:58 +00:00
|
|
|
DEFINE_int32(
|
|
|
|
data_block_index_type,
|
|
|
|
static_cast<int32_t>(
|
|
|
|
ROCKSDB_NAMESPACE::BlockBasedTableOptions().data_block_index_type),
|
|
|
|
"Index type for data blocks (see `enum DataBlockIndexType` in table.h)");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_string(db, "", "Use the db with the following name.");
|
|
|
|
|
|
|
|
DEFINE_string(secondaries_base, "",
|
|
|
|
"Use this path as the base path for secondary instances.");
|
|
|
|
|
2022-06-08 04:07:47 +00:00
|
|
|
DEFINE_bool(test_secondary, false,
|
|
|
|
"If true, start an additional secondary instance which can be used "
|
|
|
|
"for verification.");
|
2019-12-09 07:49:32 +00:00
|
|
|
|
|
|
|
DEFINE_string(
|
2021-09-28 21:12:23 +00:00
|
|
|
expected_values_dir, "",
|
2021-12-07 21:40:46 +00:00
|
|
|
"Dir where files containing info about the latest/historical values will "
|
|
|
|
"be stored. If provided and non-empty, the DB state will be verified "
|
|
|
|
"against values from these files after recovery. --max_key and "
|
|
|
|
"--column_family must be kept the same across invocations of this program "
|
|
|
|
"that use the same --expected_values_dir. Currently historical values are "
|
|
|
|
"only tracked when --sync_fault_injection is set. See --seed and "
|
|
|
|
"--nooverwritepercent for further requirements.");
|
2019-12-09 07:49:32 +00:00
|
|
|
|
|
|
|
DEFINE_bool(verify_checksum, false,
|
|
|
|
"Verify checksum for every block read from storage");
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
DEFINE_bool(mmap_read, ROCKSDB_NAMESPACE::Options().allow_mmap_reads,
|
2019-12-09 07:49:32 +00:00
|
|
|
"Allow reads to occur via mmap-ing files");
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
DEFINE_bool(mmap_write, ROCKSDB_NAMESPACE::Options().allow_mmap_writes,
|
2019-12-09 07:49:32 +00:00
|
|
|
"Allow writes to occur via mmap-ing files");
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
DEFINE_bool(use_direct_reads, ROCKSDB_NAMESPACE::Options().use_direct_reads,
|
2019-12-09 07:49:32 +00:00
|
|
|
"Use O_DIRECT for reading data");
|
|
|
|
|
|
|
|
DEFINE_bool(use_direct_io_for_flush_and_compaction,
|
2020-02-20 20:07:53 +00:00
|
|
|
ROCKSDB_NAMESPACE::Options().use_direct_io_for_flush_and_compaction,
|
2019-12-09 07:49:32 +00:00
|
|
|
"Use O_DIRECT for writing data");
|
|
|
|
|
2020-04-25 06:58:13 +00:00
|
|
|
DEFINE_bool(mock_direct_io, false,
|
|
|
|
"Mock direct IO by not using O_DIRECT for direct IO read");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_bool(statistics, false, "Create database statistics");
|
|
|
|
|
|
|
|
DEFINE_bool(sync, false, "Sync all writes to disk");
|
|
|
|
|
|
|
|
DEFINE_bool(use_fsync, false, "If true, issue fsync instead of fdatasync");
|
|
|
|
|
2022-05-05 20:21:03 +00:00
|
|
|
DEFINE_uint64(bytes_per_sync, ROCKSDB_NAMESPACE::Options().bytes_per_sync,
|
|
|
|
"If nonzero, sync SST file data incrementally after every "
|
|
|
|
"`bytes_per_sync` bytes are written");
|
|
|
|
|
|
|
|
DEFINE_uint64(wal_bytes_per_sync,
|
|
|
|
ROCKSDB_NAMESPACE::Options().wal_bytes_per_sync,
|
|
|
|
"If nonzero, sync WAL file data incrementally after every "
|
|
|
|
"`bytes_per_sync` bytes are written");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_int32(kill_random_test, 0,
|
|
|
|
"If non-zero, kill at various points in source code with "
|
|
|
|
"probability 1/this");
|
|
|
|
static const bool FLAGS_kill_random_test_dummy __attribute__((__unused__)) =
|
|
|
|
RegisterFlagValidator(&FLAGS_kill_random_test, &ValidateInt32Positive);
|
|
|
|
|
2020-06-19 22:26:05 +00:00
|
|
|
DEFINE_string(kill_exclude_prefixes, "",
|
2019-12-09 07:49:32 +00:00
|
|
|
"If non-empty, kill points with prefix in the list given will be"
|
|
|
|
" skipped. Items are comma-separated.");
|
2020-06-19 22:26:05 +00:00
|
|
|
extern std::vector<std::string> rocksdb_kill_exclude_prefixes;
|
2019-12-09 07:49:32 +00:00
|
|
|
|
|
|
|
DEFINE_bool(disable_wal, false, "If true, do not write WAL for write.");
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
DEFINE_uint64(recycle_log_file_num,
|
|
|
|
ROCKSDB_NAMESPACE::Options().recycle_log_file_num,
|
2019-12-09 07:49:32 +00:00
|
|
|
"Number of old WAL files to keep around for later recycling");
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
DEFINE_int64(target_file_size_base,
|
|
|
|
ROCKSDB_NAMESPACE::Options().target_file_size_base,
|
2019-12-09 07:49:32 +00:00
|
|
|
"Target level-1 file size for compaction");
|
|
|
|
|
|
|
|
DEFINE_int32(target_file_size_multiplier, 1,
|
|
|
|
"A multiplier to compute target level-N file size (N >= 2)");
|
|
|
|
|
|
|
|
DEFINE_uint64(max_bytes_for_level_base,
|
2020-02-20 20:07:53 +00:00
|
|
|
ROCKSDB_NAMESPACE::Options().max_bytes_for_level_base,
|
2019-12-09 07:49:32 +00:00
|
|
|
"Max bytes for level-1");
|
|
|
|
|
|
|
|
DEFINE_double(max_bytes_for_level_multiplier, 2,
|
|
|
|
"A multiplier to compute max bytes for level-N (N >= 2)");
|
|
|
|
|
|
|
|
DEFINE_int32(range_deletion_width, 10,
|
|
|
|
"The width of the range deletion intervals.");
|
|
|
|
|
|
|
|
DEFINE_uint64(rate_limiter_bytes_per_sec, 0, "Set options.rate_limiter value.");
|
|
|
|
|
|
|
|
DEFINE_bool(rate_limit_bg_reads, false,
|
|
|
|
"Use options.rate_limiter on compaction reads");
|
|
|
|
|
2022-02-17 07:17:03 +00:00
|
|
|
DEFINE_bool(rate_limit_user_ops, false,
|
|
|
|
"When true use Env::IO_USER priority level to charge internal rate "
|
|
|
|
"limiter for reads associated with user operations.");
|
|
|
|
|
Rate-limit automatic WAL flush after each user write (#9607)
Summary:
**Context:**
WAL flush is currently not rate-limited by `Options::rate_limiter`. This PR is to provide rate-limiting to auto WAL flush, the one that automatically happen after each user write operation (i.e, `Options::manual_wal_flush == false`), by adding `WriteOptions::rate_limiter_options`.
Note that we are NOT rate-limiting WAL flush that do NOT automatically happen after each user write, such as `Options::manual_wal_flush == true + manual FlushWAL()` (rate-limiting multiple WAL flushes), for the benefits of:
- being consistent with [ReadOptions::rate_limiter_priority](https://github.com/facebook/rocksdb/blob/7.0.fb/include/rocksdb/options.h#L515)
- being able to turn off some WAL flush's rate-limiting but not all (e.g, turn off specific the WAL flush of a critical user write like a service's heartbeat)
`WriteOptions::rate_limiter_options` only accept `Env::IO_USER` and `Env::IO_TOTAL` currently due to an implementation constraint.
- The constraint is that we currently queue parallel writes (including WAL writes) based on FIFO policy which does not factor rate limiter priority into this layer's scheduling. If we allow lower priorities such as `Env::IO_HIGH/MID/LOW` and such writes specified with lower priorities occurs before ones specified with higher priorities (even just by a tiny bit in arrival time), the former would have blocked the latter, leading to a "priority inversion" issue and contradictory to what we promise for rate-limiting priority. Therefore we only allow `Env::IO_USER` and `Env::IO_TOTAL` right now before improving that scheduling.
A pre-requisite to this feature is to support operation-level rate limiting in `WritableFileWriter`, which is also included in this PR.
**Summary:**
- Renamed test suite `DBRateLimiterTest to DBRateLimiterOnReadTest` for adding a new test suite
- Accept `rate_limiter_priority` in `WritableFileWriter`'s private and public write functions
- Passed `WriteOptions::rate_limiter_options` to `WritableFileWriter` in the path of automatic WAL flush.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9607
Test Plan:
- Added new unit test to verify existing flush/compaction rate-limiting does not break, since `DBTest, RateLimitingTest` is disabled and current db-level rate-limiting tests focus on read only (e.g, `db_rate_limiter_test`, `DBTest2, RateLimitedCompactionReads`).
- Added new unit test `DBRateLimiterOnWriteWALTest, AutoWalFlush`
- `strace -ftt -e trace=write ./db_bench -benchmarks=fillseq -db=/dev/shm/testdb -rate_limit_auto_wal_flush=1 -rate_limiter_bytes_per_sec=15 -rate_limiter_refill_period_us=1000000 -write_buffer_size=100000000 -disable_auto_compactions=1 -num=100`
- verified that WAL flush(i.e, system-call _write_) were chunked into 15 bytes and each _write_ was roughly 1 second apart
- verified the chunking disappeared when `-rate_limit_auto_wal_flush=0`
- crash test: `python3 tools/db_crashtest.py blackbox --disable_wal=0 --rate_limit_auto_wal_flush=1 --rate_limiter_bytes_per_sec=10485760 --interval=10` killed as normal
**Benchmarked on flush/compaction to ensure no performance regression:**
- compaction with rate-limiting (see table 1, avg over 1280-run): pre-change: **915635 micros/op**; post-change:
**907350 micros/op (improved by 0.106%)**
```
#!/bin/bash
TEST_TMPDIR=/dev/shm/testdb
START=1
NUM_DATA_ENTRY=8
N=10
rm -f compact_bmk_output.txt compact_bmk_output_2.txt dont_care_output.txt
for i in $(eval echo "{$START..$NUM_DATA_ENTRY}")
do
NUM_RUN=$(($N*(2**($i-1))))
for j in $(eval echo "{$START..$NUM_RUN}")
do
./db_bench --benchmarks=fillrandom -db=$TEST_TMPDIR -disable_auto_compactions=1 -write_buffer_size=6710886 > dont_care_output.txt && ./db_bench --benchmarks=compact -use_existing_db=1 -db=$TEST_TMPDIR -level0_file_num_compaction_trigger=1 -rate_limiter_bytes_per_sec=100000000 | egrep 'compact'
done > compact_bmk_output.txt && awk -v NUM_RUN=$NUM_RUN '{sum+=$3;sum_sqrt+=$3^2}END{print sum/NUM_RUN, sqrt(sum_sqrt/NUM_RUN-(sum/NUM_RUN)^2)}' compact_bmk_output.txt >> compact_bmk_output_2.txt
done
```
- compaction w/o rate-limiting (see table 2, avg over 640-run): pre-change: **822197 micros/op**; post-change: **823148 micros/op (regressed by 0.12%)**
```
Same as above script, except that -rate_limiter_bytes_per_sec=0
```
- flush with rate-limiting (see table 3, avg over 320-run, run on the [patch](https://github.com/hx235/rocksdb/commit/ee5c6023a9f6533fab9afdc681568daa21da4953) to augment current db_bench ): pre-change: **745752 micros/op**; post-change: **745331 micros/op (regressed by 0.06 %)**
```
#!/bin/bash
TEST_TMPDIR=/dev/shm/testdb
START=1
NUM_DATA_ENTRY=8
N=10
rm -f flush_bmk_output.txt flush_bmk_output_2.txt
for i in $(eval echo "{$START..$NUM_DATA_ENTRY}")
do
NUM_RUN=$(($N*(2**($i-1))))
for j in $(eval echo "{$START..$NUM_RUN}")
do
./db_bench -db=$TEST_TMPDIR -write_buffer_size=1048576000 -num=1000000 -rate_limiter_bytes_per_sec=100000000 -benchmarks=fillseq,flush | egrep 'flush'
done > flush_bmk_output.txt && awk -v NUM_RUN=$NUM_RUN '{sum+=$3;sum_sqrt+=$3^2}END{print sum/NUM_RUN, sqrt(sum_sqrt/NUM_RUN-(sum/NUM_RUN)^2)}' flush_bmk_output.txt >> flush_bmk_output_2.txt
done
```
- flush w/o rate-limiting (see table 4, avg over 320-run, run on the [patch](https://github.com/hx235/rocksdb/commit/ee5c6023a9f6533fab9afdc681568daa21da4953) to augment current db_bench): pre-change: **487512 micros/op**, post-change: **485856 micors/ops (improved by 0.34%)**
```
Same as above script, except that -rate_limiter_bytes_per_sec=0
```
| table 1 - compact with rate-limiting|
#-run | (pre-change) avg micros/op | std micros/op | (post-change) avg micros/op | std micros/op | change in avg micros/op (%)
-- | -- | -- | -- | -- | --
10 | 896978 | 16046.9 | 901242 | 15670.9 | 0.475373978
20 | 893718 | 15813 | 886505 | 17544.7 | -0.8070778478
40 | 900426 | 23882.2 | 894958 | 15104.5 | -0.6072681153
80 | 906635 | 21761.5 | 903332 | 23948.3 | -0.3643141948
160 | 898632 | 21098.9 | 907583 | 21145 | 0.9960695813
3.20E+02 | 905252 | 22785.5 | 908106 | 25325.5 | 0.3152713278
6.40E+02 | 905213 | 23598.6 | 906741 | 21370.5 | 0.1688000504
**1.28E+03** | **908316** | **23533.1** | **907350** | **24626.8** | **-0.1063506533**
average over #-run | 901896.25 | 21064.9625 | 901977.125 | 20592.025 | 0.008967217682
| table 2 - compact w/o rate-limiting|
#-run | (pre-change) avg micros/op | std micros/op | (post-change) avg micros/op | std micros/op | change in avg micros/op (%)
-- | -- | -- | -- | -- | --
10 | 811211 | 26996.7 | 807586 | 28456.4 | -0.4468627768
20 | 815465 | 14803.7 | 814608 | 28719.7 | -0.105093413
40 | 809203 | 26187.1 | 797835 | 25492.1 | -1.404839082
80 | 822088 | 28765.3 | 822192 | 32840.4 | 0.01265071379
160 | 821719 | 36344.7 | 821664 | 29544.9 | -0.006693285661
3.20E+02 | 820921 | 27756.4 | 821403 | 28347.7 | 0.05871454135
**6.40E+02** | **822197** | **28960.6** | **823148** | **30055.1** | **0.1156657103**
average over #-run | 8.18E+05 | 2.71E+04 | 8.15E+05 | 2.91E+04 | -0.25
| table 3 - flush with rate-limiting|
#-run | (pre-change) avg micros/op | std micros/op | (post-change) avg micros/op | std micros/op | change in avg micros/op (%)
-- | -- | -- | -- | -- | --
10 | 741721 | 11770.8 | 740345 | 5949.76 | -0.1855144994
20 | 735169 | 3561.83 | 743199 | 9755.77 | 1.09226586
40 | 743368 | 8891.03 | 742102 | 8683.22 | -0.1703059588
80 | 742129 | 8148.51 | 743417 | 9631.58| 0.1735547324
160 | 749045 | 9757.21 | 746256 | 9191.86 | -0.3723407806
**3.20E+02** | **745752** | **9819.65** | **745331** | **9840.62** | **-0.0564530836**
6.40E+02 | 749006 | 11080.5 | 748173 | 10578.7 | -0.1112140624
average over #-run | 743741.4286 | 9004.218571 | 744117.5714 | 9090.215714 | 0.05057441238
| table 4 - flush w/o rate-limiting|
#-run | (pre-change) avg micros/op | std micros/op | (post-change) avg micros/op | std micros/op | change in avg micros/op (%)
-- | -- | -- | -- | -- | --
10 | 477283 | 24719.6 | 473864 | 12379 | -0.7163464863
20 | 486743 | 20175.2 | 502296 | 23931.3 | 3.195320734
40 | 482846 | 15309.2 | 489820 | 22259.5 | 1.444352858
80 | 491490 | 21883.1 | 490071 | 23085.7 | -0.2887139108
160 | 493347 | 28074.3 | 483609 | 21211.7 | -1.973864238
**3.20E+02** | **487512** | **21401.5** | **485856** | **22195.2** | **-0.3396839462**
6.40E+02 | 490307 | 25418.6 | 485435 | 22405.2 | -0.9936631539
average over #-run | 4.87E+05 | 2.24E+04 | 4.87E+05 | 2.11E+04 | 0.00E+00
Reviewed By: ajkr
Differential Revision: D34442441
Pulled By: hx235
fbshipit-source-id: 4790f13e1e5c0a95ae1d1cc93ffcf69dc6e78bdd
2022-03-08 21:19:39 +00:00
|
|
|
DEFINE_bool(rate_limit_auto_wal_flush, false,
|
|
|
|
"When true use Env::IO_USER priority level to charge internal rate "
|
|
|
|
"limiter for automatic WAL flush (`Options::manual_wal_flush` == "
|
|
|
|
"false) after the user "
|
|
|
|
"write operation.");
|
|
|
|
|
2020-02-26 00:43:33 +00:00
|
|
|
DEFINE_uint64(sst_file_manager_bytes_per_sec, 0,
|
|
|
|
"Set `Options::sst_file_manager` to delete at this rate. By "
|
|
|
|
"default the deletion rate is unbounded.");
|
|
|
|
|
|
|
|
DEFINE_uint64(sst_file_manager_bytes_per_truncate, 0,
|
|
|
|
"Set `Options::sst_file_manager` to delete in chunks of this "
|
|
|
|
"many bytes. By default whole files will be deleted.");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_bool(use_txn, false,
|
2023-06-17 23:27:37 +00:00
|
|
|
"Use TransactionDB or OptimisticTransactionDB. When "
|
|
|
|
"use_optimistic_txn == false (by default), "
|
|
|
|
"it's (Pessimistic) TransactionDB");
|
2019-12-09 07:49:32 +00:00
|
|
|
|
2019-12-12 18:34:52 +00:00
|
|
|
DEFINE_uint64(txn_write_policy, 0,
|
|
|
|
"The transaction write policy. Default is "
|
|
|
|
"TxnDBWritePolicy::WRITE_COMMITTED. Note that this should not be "
|
2023-06-17 23:27:37 +00:00
|
|
|
"changed across crashes.");
|
|
|
|
|
|
|
|
DEFINE_bool(use_optimistic_txn, false, "Use OptimisticTransactionDB.");
|
|
|
|
DEFINE_uint64(occ_validation_policy, 1,
|
|
|
|
"Optimistic Concurrency Control Validation Policy for "
|
|
|
|
"OptimisticTransactionDB");
|
|
|
|
DEFINE_bool(share_occ_lock_buckets, false,
|
|
|
|
"Share a pool of locks across DB instances for buckets");
|
|
|
|
DEFINE_uint32(
|
|
|
|
occ_lock_bucket_count, 500,
|
|
|
|
"Bucket Count for shared Optimistic Concurrency Control (OCC) locks");
|
2019-12-12 18:34:52 +00:00
|
|
|
|
2019-12-13 18:23:01 +00:00
|
|
|
DEFINE_bool(unordered_write, false,
|
|
|
|
"Turn on the unordered_write feature. This options is currently "
|
|
|
|
"tested only in combination with use_txn=true and "
|
|
|
|
"txn_write_policy=TxnDBWritePolicy::WRITE_PREPARED.");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_int32(backup_one_in, 0,
|
|
|
|
"If non-zero, then CreateNewBackup() will be called once for "
|
|
|
|
"every N operations on average. 0 indicates CreateNewBackup() "
|
|
|
|
"is disabled.");
|
|
|
|
|
Fix, enable, and enhance backup/restore in db_stress (#7348)
Summary:
Although added to db_stress, testing of backup/restore
was never integrated into the crash test, originally concerned about
performance. I've enabled it now and to address the peformance concern,
testing backup/restore is always skipped once the db exceeds a certain
size threshold, default 100MB. This should provide sufficient
opportunity for testing BackupEngine without bogging down everything
else with heavier and heavier operations.
Also fixed backup/restore in db_stress by making sure PurgeOldBackups
can remove manifest files, which are normally kept around for db_stress.
Added more coverage of backup options, and up to three backups being
saved in one backup directory (in some cases).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/7348
Test Plan:
ran 'make blackbox_crash_test' for a while, with heightened
probabilitly of taking backups (1/10k). Also confirmed with some debug
output that the code is being covered, TestBackupRestore only takes
a few seconds to complete when triggered, and even at 1/10k and ~50MB
database, there's <,~ 1 thread testing backups at any time.
Reviewed By: ajkr
Differential Revision: D23510835
Pulled By: pdillinger
fbshipit-source-id: b6b8735591808141f81f10773ac31634cf03b6c0
2020-09-04 03:11:45 +00:00
|
|
|
DEFINE_uint64(backup_max_size, 100 * 1024 * 1024,
|
|
|
|
"If non-zero, skip checking backup/restore when DB size in "
|
|
|
|
"bytes exceeds this setting.");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_int32(checkpoint_one_in, 0,
|
|
|
|
"If non-zero, then CreateCheckpoint() will be called once for "
|
|
|
|
"every N operations on average. 0 indicates CreateCheckpoint() "
|
|
|
|
"is disabled.");
|
|
|
|
|
|
|
|
DEFINE_int32(ingest_external_file_one_in, 0,
|
|
|
|
"If non-zero, then IngestExternalFile() will be called once for "
|
|
|
|
"every N operations on average. 0 indicates IngestExternalFile() "
|
|
|
|
"is disabled.");
|
|
|
|
|
2022-06-07 22:15:09 +00:00
|
|
|
DEFINE_int32(ingest_external_file_width, 100,
|
2019-12-09 07:49:32 +00:00
|
|
|
"The width of the ingested external files.");
|
|
|
|
|
|
|
|
DEFINE_int32(compact_files_one_in, 0,
|
|
|
|
"If non-zero, then CompactFiles() will be called once for every N "
|
|
|
|
"operations on average. 0 indicates CompactFiles() is disabled.");
|
|
|
|
|
|
|
|
DEFINE_int32(compact_range_one_in, 0,
|
|
|
|
"If non-zero, then CompactRange() will be called once for every N "
|
|
|
|
"operations on average. 0 indicates CompactRange() is disabled.");
|
|
|
|
|
2024-05-09 22:37:38 +00:00
|
|
|
DEFINE_int32(promote_l0_one_in, 0,
|
|
|
|
"If non-zero, then PromoteL0() will be called once for every N "
|
|
|
|
"operations on average. 0 indicates PromoteL0() is disabled.");
|
|
|
|
|
2020-08-10 23:16:19 +00:00
|
|
|
DEFINE_int32(mark_for_compaction_one_file_in, 0,
|
|
|
|
"A `TablePropertiesCollectorFactory` will be registered, which "
|
|
|
|
"creates a `TablePropertiesCollector` with `NeedCompact()` "
|
|
|
|
"returning true once for every N files on average. 0 or negative "
|
|
|
|
"mean `NeedCompact()` always returns false.");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_int32(flush_one_in, 0,
|
|
|
|
"If non-zero, then Flush() will be called once for every N ops "
|
|
|
|
"on average. 0 indicates calls to Flush() are disabled.");
|
|
|
|
|
2024-05-09 22:37:38 +00:00
|
|
|
DEFINE_int32(key_may_exist_one_in, 0,
|
|
|
|
"If non-zero, then KeyMayExist() will be called "
|
|
|
|
"once for every N ops on average. 0 disables.");
|
|
|
|
|
|
|
|
DEFINE_int32(reset_stats_one_in, 0,
|
|
|
|
"If non-zero, then ResetStats() will be called "
|
|
|
|
"once for every N ops on average. 0 disables.");
|
|
|
|
|
2019-12-10 23:45:25 +00:00
|
|
|
DEFINE_int32(pause_background_one_in, 0,
|
|
|
|
"If non-zero, then PauseBackgroundWork()+Continue will be called "
|
|
|
|
"once for every N ops on average. 0 disables.");
|
|
|
|
|
2024-04-16 22:43:26 +00:00
|
|
|
DEFINE_int32(disable_file_deletions_one_in, 0,
|
|
|
|
"If non-zero, then DisableFileDeletions()+Enable will be called "
|
|
|
|
"once for every N ops on average. 0 disables.");
|
|
|
|
|
|
|
|
DEFINE_int32(
|
|
|
|
disable_manual_compaction_one_in, 0,
|
|
|
|
"If non-zero, then DisableManualCompaction()+Enable will be called "
|
|
|
|
"once for every N ops on average. 0 disables.");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_int32(compact_range_width, 10000,
|
|
|
|
"The width of the ranges passed to CompactRange().");
|
|
|
|
|
|
|
|
DEFINE_int32(acquire_snapshot_one_in, 0,
|
|
|
|
"If non-zero, then acquires a snapshot once every N operations on "
|
|
|
|
"average.");
|
|
|
|
|
|
|
|
DEFINE_bool(compare_full_db_state_snapshot, false,
|
|
|
|
"If set we compare state of entire db (in one of the threads) with"
|
|
|
|
"each snapshot.");
|
|
|
|
|
|
|
|
DEFINE_uint64(snapshot_hold_ops, 0,
|
|
|
|
"If non-zero, then releases snapshots N operations after they're "
|
|
|
|
"acquired.");
|
|
|
|
|
2019-12-14 23:17:05 +00:00
|
|
|
DEFINE_bool(long_running_snapshots, false,
|
|
|
|
"If set, hold on some some snapshots for much longer time.");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_bool(use_multiget, false,
|
|
|
|
"If set, use the batched MultiGet API for reads");
|
|
|
|
|
2023-03-17 21:47:29 +00:00
|
|
|
DEFINE_bool(use_get_entity, false, "If set, use the GetEntity API for reads");
|
|
|
|
|
2023-03-30 03:35:15 +00:00
|
|
|
DEFINE_bool(use_multi_get_entity, false,
|
|
|
|
"If set, use the MultiGetEntity API for reads");
|
|
|
|
|
2024-11-02 00:07:34 +00:00
|
|
|
DEFINE_int32(test_ingest_standalone_range_deletion_one_in, 0,
|
|
|
|
"If non-zero, file ingestion flow will test standalone range "
|
|
|
|
"deletion file once every N file ingestion operations.");
|
|
|
|
|
2024-11-08 05:24:21 +00:00
|
|
|
DEFINE_bool(allow_unprepared_value,
|
|
|
|
ROCKSDB_NAMESPACE::ReadOptions().allow_unprepared_value,
|
|
|
|
"Allow lazy loading of values for range scans");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
static bool ValidateInt32Percent(const char* flagname, int32_t value) {
|
|
|
|
if (value < 0 || value > 100) {
|
|
|
|
fprintf(stderr, "Invalid value for --%s: %d, 0<= pct <=100 \n", flagname,
|
|
|
|
value);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
DEFINE_int32(readpercent, 10,
|
|
|
|
"Ratio of reads to total workload (expressed as a percentage)");
|
|
|
|
static const bool FLAGS_readpercent_dummy __attribute__((__unused__)) =
|
|
|
|
RegisterFlagValidator(&FLAGS_readpercent, &ValidateInt32Percent);
|
|
|
|
|
|
|
|
DEFINE_int32(prefixpercent, 20,
|
|
|
|
"Ratio of prefix iterators to total workload (expressed as a"
|
|
|
|
" percentage)");
|
|
|
|
static const bool FLAGS_prefixpercent_dummy __attribute__((__unused__)) =
|
|
|
|
RegisterFlagValidator(&FLAGS_prefixpercent, &ValidateInt32Percent);
|
|
|
|
|
|
|
|
DEFINE_int32(writepercent, 45,
|
|
|
|
"Ratio of writes to total workload (expressed as a percentage)");
|
|
|
|
static const bool FLAGS_writepercent_dummy __attribute__((__unused__)) =
|
|
|
|
RegisterFlagValidator(&FLAGS_writepercent, &ValidateInt32Percent);
|
|
|
|
|
|
|
|
DEFINE_int32(delpercent, 15,
|
|
|
|
"Ratio of deletes to total workload (expressed as a percentage)");
|
|
|
|
static const bool FLAGS_delpercent_dummy __attribute__((__unused__)) =
|
|
|
|
RegisterFlagValidator(&FLAGS_delpercent, &ValidateInt32Percent);
|
|
|
|
|
|
|
|
DEFINE_int32(delrangepercent, 0,
|
|
|
|
"Ratio of range deletions to total workload (expressed as a "
|
|
|
|
"percentage). Cannot be used with test_batches_snapshots");
|
|
|
|
static const bool FLAGS_delrangepercent_dummy __attribute__((__unused__)) =
|
|
|
|
RegisterFlagValidator(&FLAGS_delrangepercent, &ValidateInt32Percent);
|
|
|
|
|
|
|
|
DEFINE_int32(nooverwritepercent, 60,
|
|
|
|
"Ratio of keys without overwrite to total workload (expressed as "
|
2021-10-11 23:22:10 +00:00
|
|
|
"a percentage). When --expected_values_dir is nonempty, must "
|
|
|
|
"keep this value constant across invocations.");
|
2019-12-09 07:49:32 +00:00
|
|
|
static const bool FLAGS_nooverwritepercent_dummy __attribute__((__unused__)) =
|
|
|
|
RegisterFlagValidator(&FLAGS_nooverwritepercent, &ValidateInt32Percent);
|
|
|
|
|
|
|
|
DEFINE_int32(iterpercent, 10,
|
|
|
|
"Ratio of iterations to total workload"
|
|
|
|
" (expressed as a percentage)");
|
|
|
|
static const bool FLAGS_iterpercent_dummy __attribute__((__unused__)) =
|
|
|
|
RegisterFlagValidator(&FLAGS_iterpercent, &ValidateInt32Percent);
|
|
|
|
|
|
|
|
DEFINE_uint64(num_iterations, 10, "Number of iterations per MultiIterate run");
|
|
|
|
static const bool FLAGS_num_iterations_dummy __attribute__((__unused__)) =
|
|
|
|
RegisterFlagValidator(&FLAGS_num_iterations, &ValidateUint32Range);
|
|
|
|
|
2021-12-14 21:33:16 +00:00
|
|
|
DEFINE_int32(
|
|
|
|
customopspercent, 0,
|
|
|
|
"Ratio of custom operations to total workload (expressed as a percentage)");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_string(compression_type, "snappy",
|
|
|
|
"Algorithm to use to compress the database");
|
|
|
|
|
|
|
|
DEFINE_int32(compression_max_dict_bytes, 0,
|
|
|
|
"Maximum size of dictionary used to prime the compression "
|
|
|
|
"library.");
|
|
|
|
|
|
|
|
DEFINE_int32(compression_zstd_max_train_bytes, 0,
|
|
|
|
"Maximum size of training data passed to zstd's dictionary "
|
|
|
|
"trainer.");
|
|
|
|
|
2020-04-30 17:46:54 +00:00
|
|
|
DEFINE_int32(compression_parallel_threads, 1,
|
|
|
|
"Number of threads for parallel compression.");
|
|
|
|
|
Limit buffering for collecting samples for compression dictionary (#7970)
Summary:
For dictionary compression, we need to collect some representative samples of the data to be compressed, which we use to either generate or train (when `CompressionOptions::zstd_max_train_bytes > 0`) a dictionary. Previously, the strategy was to buffer all the data blocks during flush, and up to the target file size during compaction. That strategy allowed us to randomly pick samples from as wide a range as possible that'd be guaranteed to land in a single output file.
However, some users try to make huge files in memory-constrained environments, where this strategy can cause OOM. This PR introduces an option, `CompressionOptions::max_dict_buffer_bytes`, that limits how much data blocks are buffered before we switch to unbuffered mode (which means creating the per-SST dictionary, writing out the buffered data, and compressing/writing new blocks as soon as they are built). It is not strict as we currently buffer more than just data blocks -- also keys are buffered. But it does make a step towards giving users predictable memory usage.
Related changes include:
- Changed sampling for dictionary compression to select unique data blocks when there is limited availability of data blocks
- Made use of `BlockBuilder::SwapAndReset()` to save an allocation+memcpy when buffering data blocks for building a dictionary
- Changed `ParseBoolean()` to accept an input containing characters after the boolean. This is necessary since, with this PR, a value for `CompressionOptions::enabled` is no longer necessarily the final component in the `CompressionOptions` string.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/7970
Test Plan:
- updated `CompressionOptions` unit tests to verify limit is respected (to the extent expected in the current implementation) in various scenarios of flush/compaction to bottommost/non-bottommost level
- looked at jemalloc heap profiles right before and after switching to unbuffered mode during flush/compaction. Verified memory usage in buffering is proportional to the limit set.
Reviewed By: pdillinger
Differential Revision: D26467994
Pulled By: ajkr
fbshipit-source-id: 3da4ef9fba59974e4ef40e40c01611002c861465
2021-02-19 22:06:59 +00:00
|
|
|
DEFINE_uint64(compression_max_dict_buffer_bytes, 0,
|
|
|
|
"Buffering limit for SST file data to sample for dictionary "
|
|
|
|
"compression.");
|
|
|
|
|
Support using ZDICT_finalizeDictionary to generate zstd dictionary (#9857)
Summary:
An untrained dictionary is currently simply the concatenation of several samples. The ZSTD API, ZDICT_finalizeDictionary(), can improve such a dictionary's effectiveness at low cost. This PR changes how dictionary is created by calling the ZSTD ZDICT_finalizeDictionary() API instead of creating raw content dictionary (when max_dict_buffer_bytes > 0), and pass in all buffered uncompressed data blocks as samples.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9857
Test Plan:
#### db_bench test for cpu/memory of compression+decompression and space saving on synthetic data:
Set up: change the parameter [here](https://github.com/facebook/rocksdb/blob/fb9a167a55e0970b1ef6f67c1600c8d9c4c6114f/tools/db_bench_tool.cc#L1766) to 16384 to make synthetic data more compressible.
```
# linked local ZSTD with version 1.5.2
# DEBUG_LEVEL=0 ROCKSDB_NO_FBCODE=1 ROCKSDB_DISABLE_ZSTD=1 EXTRA_CXXFLAGS="-DZSTD_STATIC_LINKING_ONLY -DZSTD -I/data/users/changyubi/install/include/" EXTRA_LDFLAGS="-L/data/users/changyubi/install/lib/ -l:libzstd.a" make -j32 db_bench
dict_bytes=16384
train_bytes=1048576
echo "========== No Dictionary =========="
TEST_TMPDIR=/dev/shm ./db_bench -benchmarks=filluniquerandom,compact -num=10000000 -compression_type=zstd -compression_max_dict_bytes=0 -block_size=4096 -max_background_jobs=24 -memtablerep=vector -allow_concurrent_memtable_write=false -disable_wal=true -max_write_buffer_number=8 >/dev/null 2>&1
TEST_TMPDIR=/dev/shm /usr/bin/time ./db_bench -use_existing_db=true -benchmarks=compact -compression_type=zstd -compression_max_dict_bytes=0 -block_size=4096 2>&1 | grep elapsed
du -hc /dev/shm/dbbench/*sst | grep total
echo "========== Raw Content Dictionary =========="
TEST_TMPDIR=/dev/shm ./db_bench_main -benchmarks=filluniquerandom,compact -num=10000000 -compression_type=zstd -compression_max_dict_bytes=$dict_bytes -block_size=4096 -max_background_jobs=24 -memtablerep=vector -allow_concurrent_memtable_write=false -disable_wal=true -max_write_buffer_number=8 >/dev/null 2>&1
TEST_TMPDIR=/dev/shm /usr/bin/time ./db_bench_main -use_existing_db=true -benchmarks=compact -compression_type=zstd -compression_max_dict_bytes=$dict_bytes -block_size=4096 2>&1 | grep elapsed
du -hc /dev/shm/dbbench/*sst | grep total
echo "========== FinalizeDictionary =========="
TEST_TMPDIR=/dev/shm ./db_bench -benchmarks=filluniquerandom,compact -num=10000000 -compression_type=zstd -compression_max_dict_bytes=$dict_bytes -compression_zstd_max_train_bytes=$train_bytes -compression_use_zstd_dict_trainer=false -block_size=4096 -max_background_jobs=24 -memtablerep=vector -allow_concurrent_memtable_write=false -disable_wal=true -max_write_buffer_number=8 >/dev/null 2>&1
TEST_TMPDIR=/dev/shm /usr/bin/time ./db_bench -use_existing_db=true -benchmarks=compact -compression_type=zstd -compression_max_dict_bytes=$dict_bytes -compression_zstd_max_train_bytes=$train_bytes -compression_use_zstd_dict_trainer=false -block_size=4096 2>&1 | grep elapsed
du -hc /dev/shm/dbbench/*sst | grep total
echo "========== TrainDictionary =========="
TEST_TMPDIR=/dev/shm ./db_bench -benchmarks=filluniquerandom,compact -num=10000000 -compression_type=zstd -compression_max_dict_bytes=$dict_bytes -compression_zstd_max_train_bytes=$train_bytes -block_size=4096 -max_background_jobs=24 -memtablerep=vector -allow_concurrent_memtable_write=false -disable_wal=true -max_write_buffer_number=8 >/dev/null 2>&1
TEST_TMPDIR=/dev/shm /usr/bin/time ./db_bench -use_existing_db=true -benchmarks=compact -compression_type=zstd -compression_max_dict_bytes=$dict_bytes -compression_zstd_max_train_bytes=$train_bytes -block_size=4096 2>&1 | grep elapsed
du -hc /dev/shm/dbbench/*sst | grep total
# Result: TrainDictionary is much better on space saving, but FinalizeDictionary seems to use less memory.
# before compression data size: 1.2GB
dict_bytes=16384
max_dict_buffer_bytes = 1048576
space cpu/memory
No Dictionary 468M 14.93user 1.00system 0:15.92elapsed 100%CPU (0avgtext+0avgdata 23904maxresident)k
Raw Dictionary 251M 15.81user 0.80system 0:16.56elapsed 100%CPU (0avgtext+0avgdata 156808maxresident)k
FinalizeDictionary 236M 11.93user 0.64system 0:12.56elapsed 100%CPU (0avgtext+0avgdata 89548maxresident)k
TrainDictionary 84M 7.29user 0.45system 0:07.75elapsed 100%CPU (0avgtext+0avgdata 97288maxresident)k
```
#### Benchmark on 10 sample SST files for spacing saving and CPU time on compression:
FinalizeDictionary is comparable to TrainDictionary in terms of space saving, and takes less time in compression.
```
dict_bytes=16384
train_bytes=1048576
for sst_file in `ls ../temp/myrock-sst/`
do
echo "********** $sst_file **********"
echo "========== No Dictionary =========="
./sst_dump --file="../temp/myrock-sst/$sst_file" --command=recompress --compression_level_from=6 --compression_level_to=6 --compression_types=kZSTD
echo "========== Raw Content Dictionary =========="
./sst_dump --file="../temp/myrock-sst/$sst_file" --command=recompress --compression_level_from=6 --compression_level_to=6 --compression_types=kZSTD --compression_max_dict_bytes=$dict_bytes
echo "========== FinalizeDictionary =========="
./sst_dump --file="../temp/myrock-sst/$sst_file" --command=recompress --compression_level_from=6 --compression_level_to=6 --compression_types=kZSTD --compression_max_dict_bytes=$dict_bytes --compression_zstd_max_train_bytes=$train_bytes --compression_use_zstd_finalize_dict
echo "========== TrainDictionary =========="
./sst_dump --file="../temp/myrock-sst/$sst_file" --command=recompress --compression_level_from=6 --compression_level_to=6 --compression_types=kZSTD --compression_max_dict_bytes=$dict_bytes --compression_zstd_max_train_bytes=$train_bytes
done
010240.sst (Size/Time) 011029.sst 013184.sst 021552.sst 185054.sst 185137.sst 191666.sst 7560381.sst 7604174.sst 7635312.sst
No Dictionary 28165569 / 2614419 32899411 / 2976832 32977848 / 3055542 31966329 / 2004590 33614351 / 1755877 33429029 / 1717042 33611933 / 1776936 33634045 / 2771417 33789721 / 2205414 33592194 / 388254
Raw Content Dictionary 28019950 / 2697961 33748665 / 3572422 33896373 / 3534701 26418431 / 2259658 28560825 / 1839168 28455030 / 1846039 28494319 / 1861349 32391599 / 3095649 33772142 / 2407843 33592230 / 474523
FinalizeDictionary 27896012 / 2650029 33763886 / 3719427 33904283 / 3552793 26008225 / 2198033 28111872 / 1869530 28014374 / 1789771 28047706 / 1848300 32296254 / 3204027 33698698 / 2381468 33592344 / 517433
TrainDictionary 28046089 / 2740037 33706480 / 3679019 33885741 / 3629351 25087123 / 2204558 27194353 / 1970207 27234229 / 1896811 27166710 / 1903119 32011041 / 3322315 32730692 / 2406146 33608631 / 570593
```
#### Decompression/Read test:
With FinalizeDictionary/TrainDictionary, some data structure used for decompression are in stored in dictionary, so they are expected to be faster in terms of decompression/reads.
```
dict_bytes=16384
train_bytes=1048576
echo "No Dictionary"
TEST_TMPDIR=/dev/shm/ ./db_bench -benchmarks=filluniquerandom,compact -compression_type=zstd -compression_max_dict_bytes=0 > /dev/null 2>&1
TEST_TMPDIR=/dev/shm/ ./db_bench -use_existing_db=true -benchmarks=readrandom -cache_size=0 -compression_type=zstd -compression_max_dict_bytes=0 2>&1 | grep MB/s
echo "Raw Dictionary"
TEST_TMPDIR=/dev/shm/ ./db_bench -benchmarks=filluniquerandom,compact -compression_type=zstd -compression_max_dict_bytes=$dict_bytes > /dev/null 2>&1
TEST_TMPDIR=/dev/shm/ ./db_bench -use_existing_db=true -benchmarks=readrandom -cache_size=0 -compression_type=zstd -compression_max_dict_bytes=$dict_bytes 2>&1 | grep MB/s
echo "FinalizeDict"
TEST_TMPDIR=/dev/shm/ ./db_bench -benchmarks=filluniquerandom,compact -compression_type=zstd -compression_max_dict_bytes=$dict_bytes -compression_zstd_max_train_bytes=$train_bytes -compression_use_zstd_dict_trainer=false > /dev/null 2>&1
TEST_TMPDIR=/dev/shm/ ./db_bench -use_existing_db=true -benchmarks=readrandom -cache_size=0 -compression_type=zstd -compression_max_dict_bytes=$dict_bytes -compression_zstd_max_train_bytes=$train_bytes -compression_use_zstd_dict_trainer=false 2>&1 | grep MB/s
echo "Train Dictionary"
TEST_TMPDIR=/dev/shm/ ./db_bench -benchmarks=filluniquerandom,compact -compression_type=zstd -compression_max_dict_bytes=$dict_bytes -compression_zstd_max_train_bytes=$train_bytes > /dev/null 2>&1
TEST_TMPDIR=/dev/shm/ ./db_bench -use_existing_db=true -benchmarks=readrandom -cache_size=0 -compression_type=zstd -compression_max_dict_bytes=$dict_bytes -compression_zstd_max_train_bytes=$train_bytes 2>&1 | grep MB/s
No Dictionary
readrandom : 12.183 micros/op 82082 ops/sec 12.183 seconds 1000000 operations; 9.1 MB/s (1000000 of 1000000 found)
Raw Dictionary
readrandom : 12.314 micros/op 81205 ops/sec 12.314 seconds 1000000 operations; 9.0 MB/s (1000000 of 1000000 found)
FinalizeDict
readrandom : 9.787 micros/op 102180 ops/sec 9.787 seconds 1000000 operations; 11.3 MB/s (1000000 of 1000000 found)
Train Dictionary
readrandom : 9.698 micros/op 103108 ops/sec 9.699 seconds 1000000 operations; 11.4 MB/s (1000000 of 1000000 found)
```
Reviewed By: ajkr
Differential Revision: D35720026
Pulled By: cbi42
fbshipit-source-id: 24d230fdff0fd28a1bb650658798f00dfcfb2a1f
2022-05-20 19:09:09 +00:00
|
|
|
DEFINE_bool(
|
|
|
|
compression_use_zstd_dict_trainer, true,
|
|
|
|
"Use zstd's trainer to generate dictionary. If the options is false, "
|
|
|
|
"zstd's finalizeDictionary() API is used to generate dictionary. "
|
|
|
|
"ZSTD 1.4.5+ is required. If ZSTD 1.4.5+ is not linked with the binary, "
|
|
|
|
"this flag will have the default value true.");
|
|
|
|
|
Add `CompressionOptions::checksum` for enabling ZSTD checksum (#11666)
Summary:
Optionally enable zstd checksum flag (https://github.com/facebook/zstd/blob/d857369028d997c92ff1f1861a4d7f679a125464/lib/zstd.h#L428) to detect corruption during decompression. Main changes are in compression.h:
* User can set CompressionOptions::checksum to true to enable this feature.
* We enable this feature in ZSTD by setting the checksum flag in ZSTD compression context: `ZSTD_CCtx`.
* Uses `ZSTD_compress2()` to do compression since it supports frame parameter like the checksum flag. Compression level is also set in compression context as a flag.
* Error handling during decompression to propagate error message from ZSTD.
* Updated microbench to test read performance impact.
About compatibility, the current compression decoders should continue to work with the data created by the new compression API `ZSTD_compress2()`: https://github.com/facebook/zstd/issues/3711.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11666
Test Plan:
* Existing unit tests for zstd compression
* Add unit test `DBTest2.ZSTDChecksum` to test the corruption case
* Manually tested that compression levels, parallel compression, dictionary compression, index compression all work with the new ZSTD_compress2() API.
* Manually tested with `sst_dump --command=recompress` that different compression levels and dictionary compression settings all work.
* Manually tested compiling with older versions of ZSTD: v1.3.8, v1.1.0, v0.6.2.
* Perf impact: from public benchmark data: http://fastcompression.blogspot.com/2019/03/presenting-xxh3.html for checksum and https://github.com/facebook/zstd#benchmarks, if decompression is 1700MB/s and checksum computation is 70000MB/s, checksum computation is an additional ~2.4% time for decompression. Compression is slower and checksumming should be less noticeable.
* Microbench:
```
TEST_TMPDIR=/dev/shm ./branch_db_basic_bench --benchmark_filter=DBGet/comp_style:0/max_data:1048576/per_key_size:256/enable_statistics:0/negative_query:0/enable_filter:0/mmap:0/compression_type:7/compression_checksum:1/no_blockcache:1/iterations:10000/threads:1 --benchmark_repetitions=100
Min out of 100 runs:
Main:
10390 10436 10456 10484 10499 10535 10544 10545 10565 10568
After this PR, checksum=false
10285 10397 10503 10508 10515 10557 10562 10635 10640 10660
After this PR, checksum=true
10827 10876 10925 10949 10971 11052 11061 11063 11100 11109
```
* db_bench:
```
Write perf
TEST_TMPDIR=/dev/shm/ ./db_bench_ichecksum --benchmarks=fillseq[-X10] --compression_type=zstd --num=10000000 --compression_checksum=..
[FillSeq checksum=0]
fillseq [AVG 10 runs] : 281635 (± 31711) ops/sec; 31.2 (± 3.5) MB/sec
fillseq [MEDIAN 10 runs] : 294027 ops/sec; 32.5 MB/sec
[FillSeq checksum=1]
fillseq [AVG 10 runs] : 286961 (± 34700) ops/sec; 31.7 (± 3.8) MB/sec
fillseq [MEDIAN 10 runs] : 283278 ops/sec; 31.3 MB/sec
Read perf
TEST_TMPDIR=/dev/shm ./db_bench_ichecksum --benchmarks=readrandom[-X20] --num=100000000 --reads=1000000 --use_existing_db=true --readonly=1
[Readrandom checksum=1]
readrandom [AVG 20 runs] : 360928 (± 3579) ops/sec; 4.0 (± 0.0) MB/sec
readrandom [MEDIAN 20 runs] : 362468 ops/sec; 4.0 MB/sec
[Readrandom checksum=0]
readrandom [AVG 20 runs] : 380365 (± 2384) ops/sec; 4.2 (± 0.0) MB/sec
readrandom [MEDIAN 20 runs] : 379800 ops/sec; 4.2 MB/sec
Compression
TEST_TMPDIR=/dev/shm ./db_bench_ichecksum --benchmarks=compress[-X20] --compression_type=zstd --num=100000000 --compression_checksum=1
checksum=1
compress [AVG 20 runs] : 54074 (± 634) ops/sec; 211.2 (± 2.5) MB/sec
compress [MEDIAN 20 runs] : 54396 ops/sec; 212.5 MB/sec
checksum=0
compress [AVG 20 runs] : 54598 (± 393) ops/sec; 213.3 (± 1.5) MB/sec
compress [MEDIAN 20 runs] : 54592 ops/sec; 213.3 MB/sec
Decompression:
TEST_TMPDIR=/dev/shm ./db_bench_ichecksum --benchmarks=uncompress[-X20] --compression_type=zstd --compression_checksum=1
checksum = 0
uncompress [AVG 20 runs] : 167499 (± 962) ops/sec; 654.3 (± 3.8) MB/sec
uncompress [MEDIAN 20 runs] : 167210 ops/sec; 653.2 MB/sec
checksum = 1
uncompress [AVG 20 runs] : 167980 (± 924) ops/sec; 656.2 (± 3.6) MB/sec
uncompress [MEDIAN 20 runs] : 168465 ops/sec; 658.1 MB/sec
```
Reviewed By: ajkr
Differential Revision: D48019378
Pulled By: cbi42
fbshipit-source-id: 674120c6e1853c2ced1436ac8138559d0204feba
2023-08-18 22:01:59 +00:00
|
|
|
DEFINE_bool(compression_checksum, false,
|
|
|
|
"Turn on zstd's checksum feature for detecting corruption.");
|
|
|
|
|
2019-12-21 00:13:19 +00:00
|
|
|
DEFINE_string(bottommost_compression_type, "disable",
|
|
|
|
"Algorithm to use to compress bottommost level of the database. "
|
|
|
|
"\"disable\" means disabling the feature");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_string(checksum_type, "kCRC32c", "Algorithm to use to checksum blocks");
|
|
|
|
|
2022-01-25 03:56:37 +00:00
|
|
|
DEFINE_string(env_uri, "",
|
|
|
|
"URI for env lookup. Mutually exclusive with --fs_uri");
|
2020-08-17 18:51:45 +00:00
|
|
|
|
|
|
|
DEFINE_string(fs_uri, "",
|
|
|
|
"URI for registry Filesystem lookup. Mutually exclusive"
|
2022-01-25 03:56:37 +00:00
|
|
|
" with --env_uri."
|
2020-08-17 18:51:45 +00:00
|
|
|
" Creates a default environment with the specified filesystem.");
|
2019-12-09 07:49:32 +00:00
|
|
|
|
|
|
|
DEFINE_uint64(ops_per_thread, 1200000, "Number of operations per thread.");
|
|
|
|
static const bool FLAGS_ops_per_thread_dummy __attribute__((__unused__)) =
|
|
|
|
RegisterFlagValidator(&FLAGS_ops_per_thread, &ValidateUint32Range);
|
|
|
|
|
|
|
|
DEFINE_uint64(log2_keys_per_lock, 2, "Log2 of number of keys per lock");
|
|
|
|
static const bool FLAGS_log2_keys_per_lock_dummy __attribute__((__unused__)) =
|
|
|
|
RegisterFlagValidator(&FLAGS_log2_keys_per_lock, &ValidateUint32Range);
|
|
|
|
|
|
|
|
DEFINE_uint64(max_manifest_file_size, 16384, "Maximum size of a MANIFEST file");
|
|
|
|
|
|
|
|
DEFINE_bool(in_place_update, false, "On true, does inplace update in memtable");
|
|
|
|
|
|
|
|
DEFINE_string(memtablerep, "skip_list", "");
|
|
|
|
|
|
|
|
inline static bool ValidatePrefixSize(const char* flagname, int32_t value) {
|
|
|
|
if (value < -1 || value > 8) {
|
|
|
|
fprintf(stderr, "Invalid value for --%s: %d. -1 <= PrefixSize <= 8\n",
|
|
|
|
flagname, value);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
DEFINE_int32(prefix_size, 7,
|
|
|
|
"Control the prefix size for HashSkipListRep. "
|
|
|
|
"-1 is disabled.");
|
|
|
|
static const bool FLAGS_prefix_size_dummy __attribute__((__unused__)) =
|
|
|
|
RegisterFlagValidator(&FLAGS_prefix_size, &ValidatePrefixSize);
|
|
|
|
|
|
|
|
DEFINE_bool(use_merge, false,
|
|
|
|
"On true, replaces all writes with a Merge "
|
|
|
|
"that behaves like a Put");
|
|
|
|
|
Add the PutEntity API to the stress/crash tests (#10760)
Summary:
The patch adds the `PutEntity` API to the non-batched, batched, and
CF consistency stress tests. Namely, when the new `db_stress` command
line parameter `use_put_entity_one_in` is greater than zero, one in
N writes on average is performed using `PutEntity` rather than `Put`.
The wide-column entity written has the generated value in its default
column; in addition, it contains up to three additional columns where
the original generated value is divided up between the column name and the
column value (with the column name containing the first k characters of
the generated value, and the column value containing the rest). Whether
`PutEntity` is used (and if so, how many columns the entity has) is completely
determined by the "value base" used to generate the value (that is, there is
no randomness involved). Assuming the same `use_put_entity_one_in` setting
is used across `db_stress` invocations, this enables us to reconstruct and
validate the entity during subsequent `db_stress` runs.
Note that `PutEntity` is currently incompatible with `Merge`, transactions, and
user-defined timestamps; these combinations are currently disabled/disallowed.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/10760
Test Plan: Ran some batched, non-batched, and CF consistency stress tests using the script.
Reviewed By: riversand963
Differential Revision: D39939032
Pulled By: ltamasi
fbshipit-source-id: eafdf124e95993fb7d73158e3b006d11819f7fa9
2022-09-30 18:11:07 +00:00
|
|
|
DEFINE_uint32(use_put_entity_one_in, 0,
|
|
|
|
"If greater than zero, PutEntity will be used once per every N "
|
|
|
|
"write ops on average.");
|
|
|
|
|
2024-05-09 23:40:22 +00:00
|
|
|
DEFINE_bool(use_attribute_group, false,
|
|
|
|
"If set, use the attribute_group API to put/get entities");
|
|
|
|
|
2024-05-31 17:50:15 +00:00
|
|
|
DEFINE_bool(use_multi_cf_iterator, false,
|
|
|
|
"If set, use the multi_cf_iterator for TestIterate");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
DEFINE_bool(use_full_merge_v1, false,
|
|
|
|
"On true, use a merge operator that implement the deprecated "
|
|
|
|
"version of FullMerge");
|
2019-12-11 05:53:43 +00:00
|
|
|
|
|
|
|
DEFINE_int32(sync_wal_one_in, 0,
|
|
|
|
"If non-zero, then SyncWAL() will be called once for every N ops "
|
|
|
|
"on average. 0 indicates that calls to SyncWAL() are disabled.");
|
2019-12-16 23:24:26 +00:00
|
|
|
|
|
|
|
DEFINE_bool(avoid_unnecessary_blocking_io,
|
2020-02-20 20:07:53 +00:00
|
|
|
ROCKSDB_NAMESPACE::Options().avoid_unnecessary_blocking_io,
|
2019-12-16 23:24:26 +00:00
|
|
|
"If true, some expensive cleaning up operations will be moved from "
|
|
|
|
"user reads to high-pri background threads.");
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
DEFINE_bool(write_dbid_to_manifest,
|
|
|
|
ROCKSDB_NAMESPACE::Options().write_dbid_to_manifest,
|
2019-12-16 23:24:26 +00:00
|
|
|
"Write DB_ID to manifest");
|
|
|
|
|
2024-09-19 21:05:21 +00:00
|
|
|
DEFINE_bool(write_identity_file,
|
|
|
|
ROCKSDB_NAMESPACE::Options().write_identity_file,
|
|
|
|
"Write DB_ID to IDENTITY file");
|
|
|
|
|
2020-04-16 19:09:18 +00:00
|
|
|
DEFINE_bool(avoid_flush_during_recovery,
|
|
|
|
ROCKSDB_NAMESPACE::Options().avoid_flush_during_recovery,
|
|
|
|
"Avoid flush during recovery");
|
|
|
|
|
2019-12-16 23:24:26 +00:00
|
|
|
DEFINE_uint64(max_write_batch_group_size_bytes,
|
2020-02-20 20:07:53 +00:00
|
|
|
ROCKSDB_NAMESPACE::Options().max_write_batch_group_size_bytes,
|
2019-12-16 23:24:26 +00:00
|
|
|
"Max write batch group size");
|
|
|
|
|
|
|
|
DEFINE_bool(level_compaction_dynamic_level_bytes,
|
2020-02-20 20:07:53 +00:00
|
|
|
ROCKSDB_NAMESPACE::Options().level_compaction_dynamic_level_bytes,
|
2019-12-16 23:24:26 +00:00
|
|
|
"Use dynamic level");
|
|
|
|
|
2019-12-18 04:43:06 +00:00
|
|
|
DEFINE_int32(verify_checksum_one_in, 0,
|
|
|
|
"If non-zero, then DB::VerifyChecksum() will be called to do"
|
|
|
|
" checksum verification of all the files in the database once for"
|
|
|
|
" every N ops on average. 0 indicates that calls to"
|
|
|
|
" VerifyChecksum() are disabled.");
|
Group rocksdb.sst.read.micros stat by different user read IOActivity + misc (#11444)
Summary:
**Context/Summary:**
- Similar to https://github.com/facebook/rocksdb/pull/11288 but for user read such as `Get(), MultiGet(), DBIterator::XXX(), Verify(File)Checksum()`.
- For this, I refactored some user-facing `MultiGet` calls in `TransactionBase` and various types of `DB` so that it does not call a user-facing `Get()` but `GetImpl()` for passing the `ReadOptions::io_activity` check (see PR conversation)
- New user read stats breakdown are guarded by `kExceptDetailedTimers` since measurement shows they have 4-5% regression to the upstream/main.
- Misc
- More refactoring: with https://github.com/facebook/rocksdb/pull/11288, we complete passing `ReadOptions/IOOptions` to FS level. So we can now replace the previously [added](https://github.com/facebook/rocksdb/pull/9424) `rate_limiter_priority` parameter in `RandomAccessFileReader`'s `Read/MultiRead/Prefetch()` with `IOOptions::rate_limiter_priority`
- Also, `ReadAsync()` call time is measured in `SST_READ_MICRO` now
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11444
Test Plan:
- CI fake db crash/stress test
- Microbenchmarking
**Build** `make clean && ROCKSDB_NO_FBCODE=1 DEBUG_LEVEL=0 make -jN db_basic_bench`
- google benchmark version: https://github.com/google/benchmark/commit/604f6fd3f4b34a84ec4eb4db81d842fa4db829cd
- db_basic_bench_base: upstream
- db_basic_bench_pr: db_basic_bench_base + this PR
- asyncread_db_basic_bench_base: upstream + [db basic bench patch for IteratorNext](https://github.com/facebook/rocksdb/compare/main...hx235:rocksdb:micro_bench_async_read)
- asyncread_db_basic_bench_pr: asyncread_db_basic_bench_base + this PR
**Test**
Get
```
TEST_TMPDIR=/dev/shm ./db_basic_bench_{null_stat|base|pr} --benchmark_filter=DBGet/comp_style:0/max_data:134217728/per_key_size:256/enable_statistics:1/negative_query:0/enable_filter:0/mmap:1/threads:1 --benchmark_repetitions=1000
```
Result
```
Coming soon
```
AsyncRead
```
TEST_TMPDIR=/dev/shm ./asyncread_db_basic_bench_{base|pr} --benchmark_filter=IteratorNext/comp_style:0/max_data:134217728/per_key_size:256/enable_statistics:1/async_io:1/include_detailed_timers:0 --benchmark_repetitions=1000 > syncread_db_basic_bench_{base|pr}.out
```
Result
```
Base:
1956,1956,1968,1977,1979,1986,1988,1988,1988,1990,1991,1991,1993,1993,1993,1993,1994,1996,1997,1997,1997,1998,1999,2001,2001,2002,2004,2007,2007,2008,
PR (2.3% regression, due to measuring `SST_READ_MICRO` that wasn't measured before):
1993,2014,2016,2022,2024,2027,2027,2028,2028,2030,2031,2031,2032,2032,2038,2039,2042,2044,2044,2047,2047,2047,2048,2049,2050,2052,2052,2052,2053,2053,
```
Reviewed By: ajkr
Differential Revision: D45918925
Pulled By: hx235
fbshipit-source-id: 58a54560d9ebeb3a59b6d807639692614dad058a
2023-08-09 00:26:50 +00:00
|
|
|
|
|
|
|
DEFINE_int32(verify_file_checksums_one_in, 0,
|
|
|
|
"If non-zero, then DB::VerifyFileChecksums() will be called to do"
|
|
|
|
" checksum verification of all the files in the database once for"
|
|
|
|
" every N ops on average. 0 indicates that calls to"
|
|
|
|
" VerifyFileChecksums() are disabled.");
|
|
|
|
|
2019-12-20 16:46:52 +00:00
|
|
|
DEFINE_int32(verify_db_one_in, 0,
|
|
|
|
"If non-zero, call VerifyDb() once for every N ops. 0 indicates "
|
|
|
|
"that VerifyDb() will not be called in OperateDb(). Note that "
|
|
|
|
"enabling this can slow down tests.");
|
|
|
|
|
|
|
|
DEFINE_int32(continuous_verification_interval, 1000,
|
|
|
|
"While test is running, verify db every N milliseconds. 0 "
|
|
|
|
"disables continuous verification.");
|
2019-12-21 05:42:19 +00:00
|
|
|
|
|
|
|
DEFINE_int32(approximate_size_one_in, 64,
|
Re-implement GetApproximateMemTableStats for skip lists (#13047)
Summary:
GetApproximateMemTableStats() could return some bad results with the standard skip list memtable. See this new db_bench test showing the dismal distribution of results when the actual number of entries in range is 1000:
```
$ ./db_bench --benchmarks=filluniquerandom,approximatememtablestats,readrandom --value_size=1 --num=1000000 --batch_size=1000
...
filluniquerandom : 1.391 micros/op 718915 ops/sec 1.391 seconds 1000000 operations; 11.7 MB/s
approximatememtablestats : 3.711 micros/op 269492 ops/sec 3.711 seconds 1000000 operations;
Reported entry count stats (expected 1000):
Count: 1000000 Average: 2344.1611 StdDev: 26587.27
Min: 0 Median: 965.8555 Max: 835273
Percentiles: P50: 965.86 P75: 1610.77 P99: 12618.01 P99.9: 74991.58 P99.99: 830970.97
------------------------------------------------------
[ 0, 1 ] 131344 13.134% 13.134% ###
( 1, 2 ] 115 0.011% 13.146%
( 2, 3 ] 106 0.011% 13.157%
( 3, 4 ] 190 0.019% 13.176%
( 4, 6 ] 214 0.021% 13.197%
( 6, 10 ] 522 0.052% 13.249%
( 10, 15 ] 748 0.075% 13.324%
( 15, 22 ] 1002 0.100% 13.424%
( 22, 34 ] 1948 0.195% 13.619%
( 34, 51 ] 3067 0.307% 13.926%
( 51, 76 ] 4213 0.421% 14.347%
( 76, 110 ] 5721 0.572% 14.919%
( 110, 170 ] 11375 1.137% 16.056%
( 170, 250 ] 17928 1.793% 17.849%
( 250, 380 ] 36597 3.660% 21.509% #
( 380, 580 ] 77882 7.788% 29.297% ##
( 580, 870 ] 160193 16.019% 45.317% ###
( 870, 1300 ] 210098 21.010% 66.326% ####
( 1300, 1900 ] 167461 16.746% 83.072% ###
( 1900, 2900 ] 78678 7.868% 90.940% ##
( 2900, 4400 ] 47743 4.774% 95.715% #
( 4400, 6600 ] 17650 1.765% 97.480%
( 6600, 9900 ] 11895 1.190% 98.669%
( 9900, 14000 ] 4993 0.499% 99.168%
( 14000, 22000 ] 2384 0.238% 99.407%
( 22000, 33000 ] 1966 0.197% 99.603%
( 50000, 75000 ] 2968 0.297% 99.900%
( 570000, 860000 ] 999 0.100% 100.000%
readrandom : 1.967 micros/op 508487 ops/sec 1.967 seconds 1000000 operations; 8.2 MB/s (1000000 of 1000000 found)
```
Perhaps the only good thing to say about the old implementation was that it was fast, though apparently not that fast.
I've implemented a much more robust and reasonably fast new version of the function. It's still logarithmic but with some larger constant factors. The standard deviation from true count is around 20% or less, and roughly the CPU cost of two memtable point look-ups. See code comments for detail.
```
$ ./db_bench --benchmarks=filluniquerandom,approximatememtablestats,readrandom --value_size=1 --num=1000000 --batch_size=1000
...
filluniquerandom : 1.478 micros/op 676434 ops/sec 1.478 seconds 1000000 operations; 11.0 MB/s
approximatememtablestats : 2.694 micros/op 371157 ops/sec 2.694 seconds 1000000 operations;
Reported entry count stats (expected 1000):
Count: 1000000 Average: 1073.5158 StdDev: 197.80
Min: 608 Median: 1079.9506 Max: 2176
Percentiles: P50: 1079.95 P75: 1223.69 P99: 1852.36 P99.9: 1898.70 P99.99: 2176.00
------------------------------------------------------
( 580, 870 ] 134848 13.485% 13.485% ###
( 870, 1300 ] 747868 74.787% 88.272% ###############
( 1300, 1900 ] 116536 11.654% 99.925% ##
( 1900, 2900 ] 748 0.075% 100.000%
readrandom : 1.997 micros/op 500654 ops/sec 1.997 seconds 1000000 operations; 8.1 MB/s (1000000 of 1000000 found)
```
We can already see that the distribution of results is dramatically better and wonderfully normal-looking, with relative standard deviation around 20%. The function is also FASTER, at least with these parameters. Let's look how this behavior generalizes, first *much* larger range:
```
$ ./db_bench --benchmarks=filluniquerandom,approximatememtablestats,readrandom --value_size=1 --num=1000000 --batch_size=30000
filluniquerandom : 1.390 micros/op 719654 ops/sec 1.376 seconds 990000 operations; 11.7 MB/s
approximatememtablestats : 1.129 micros/op 885649 ops/sec 1.129 seconds 1000000 operations;
Reported entry count stats (expected 30000):
Count: 1000000 Average: 31098.8795 StdDev: 3601.47
Min: 21504 Median: 29333.9303 Max: 43008
Percentiles: P50: 29333.93 P75: 33018.00 P99: 43008.00 P99.9: 43008.00 P99.99: 43008.00
------------------------------------------------------
( 14000, 22000 ] 408 0.041% 0.041%
( 22000, 33000 ] 749327 74.933% 74.974% ###############
( 33000, 50000 ] 250265 25.027% 100.000% #####
readrandom : 1.894 micros/op 528083 ops/sec 1.894 seconds 1000000 operations; 8.5 MB/s (989989 of 1000000 found)
```
This is *even faster* and relatively *more accurate*, with relative standard deviation closer to 10%. Code comments explain why. Now let's look at smaller ranges. Implementation quirks or conveniences:
* When actual number in range is >= 40, the minimum return value is 40.
* When the actual is <= 10, it is guaranteed to return that actual number.
```
$ ./db_bench --benchmarks=filluniquerandom,approximatememtablestats,readrandom --value_size=1 --num=1000000 --batch_size=75
...
filluniquerandom : 1.417 micros/op 705668 ops/sec 1.417 seconds 999975 operations; 11.4 MB/s
approximatememtablestats : 3.342 micros/op 299197 ops/sec 3.342 seconds 1000000 operations;
Reported entry count stats (expected 75):
Count: 1000000 Average: 75.1210 StdDev: 15.02
Min: 40 Median: 71.9395 Max: 256
Percentiles: P50: 71.94 P75: 89.69 P99: 119.12 P99.9: 166.68 P99.99: 229.78
------------------------------------------------------
( 34, 51 ] 38867 3.887% 3.887% #
( 51, 76 ] 550554 55.055% 58.942% ###########
( 76, 110 ] 398854 39.885% 98.828% ########
( 110, 170 ] 11353 1.135% 99.963%
( 170, 250 ] 364 0.036% 99.999%
( 250, 380 ] 8 0.001% 100.000%
readrandom : 1.861 micros/op 537224 ops/sec 1.861 seconds 1000000 operations; 8.7 MB/s (999974 of 1000000 found)
$ ./db_bench --benchmarks=filluniquerandom,approximatememtablestats,readrandom --value_size=1 --num=1000000 --batch_size=25
...
filluniquerandom : 1.501 micros/op 666283 ops/sec 1.501 seconds 1000000 operations; 10.8 MB/s
approximatememtablestats : 5.118 micros/op 195401 ops/sec 5.118 seconds 1000000 operations;
Reported entry count stats (expected 25):
Count: 1000000 Average: 26.2392 StdDev: 4.58
Min: 25 Median: 28.4590 Max: 72
Percentiles: P50: 28.46 P75: 31.69 P99: 49.27 P99.9: 67.95 P99.99: 72.00
------------------------------------------------------
( 22, 34 ] 928936 92.894% 92.894% ###################
( 34, 51 ] 67960 6.796% 99.690% #
( 51, 76 ] 3104 0.310% 100.000%
readrandom : 1.892 micros/op 528595 ops/sec 1.892 seconds 1000000 operations; 8.6 MB/s (1000000 of 1000000 found)
$ ./db_bench --benchmarks=filluniquerandom,approximatememtablestats,readrandom --value_size=1 --num=1000000 --batch_size=10
...
filluniquerandom : 1.642 micros/op 608916 ops/sec 1.642 seconds 1000000 operations; 9.9 MB/s
approximatememtablestats : 3.042 micros/op 328721 ops/sec 3.042 seconds 1000000 operations;
Reported entry count stats (expected 10):
Count: 1000000 Average: 10.0000 StdDev: 0.00
Min: 10 Median: 10.0000 Max: 10
Percentiles: P50: 10.00 P75: 10.00 P99: 10.00 P99.9: 10.00 P99.99: 10.00
------------------------------------------------------
( 6, 10 ] 1000000 100.000% 100.000% ####################
readrandom : 1.805 micros/op 554126 ops/sec 1.805 seconds 1000000 operations; 9.0 MB/s (1000000 of 1000000 found)
```
Remarkably consistent.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/13047
Test Plan: new db_bench test for both performance and accuracy (see above); added to crash test; unit test updated.
Reviewed By: cbi42
Differential Revision: D63722003
Pulled By: pdillinger
fbshipit-source-id: cfc8613c085e87c17ecec22d82601aac2a5a1b26
2024-10-02 21:25:50 +00:00
|
|
|
"If non-zero, DB::GetApproximateSizes() and "
|
|
|
|
"DB::GetApproximateMemTableStats() will be called against "
|
|
|
|
"random key ranges.");
|
2020-04-11 00:18:56 +00:00
|
|
|
|
|
|
|
DEFINE_int32(read_fault_one_in, 1000,
|
2022-06-03 03:04:33 +00:00
|
|
|
"On non-zero, enables fault injection on read");
|
2020-04-16 18:10:53 +00:00
|
|
|
|
Inject more errors to more files in stress test (#12713)
Summary:
**Context:**
We currently have partial error injection:
- DB operation: all read, SST write
- DB open: all read, SST write, all metadata write.
This PR completes the error injection (with some limitations below):
- DB operation & open: all read, all write, all metadata write, all metadata read
**Summary:**
- Inject retryable metadata read, metadata write error concerning directory (e.g, dir sync, ) or file metadata (e.g, name, size, file creation/deletion...)
- Inject retryable errors to all major file types: random access file, sequential file, writable file
- Allow db stress test operations to handle above injected errors gracefully without crashing
- Change all error injection to thread-local implementation for easier disabling and enabling in the same thread. For example, we can control error handling thread to have no error injection. It's also cleaner in code.
- Limitation: compared to before, we now don't have write fault injection for backup/restore CopyOrCreateFiles work threads since they use anonymous background threads as well as read injection for db open bg thread
- Add a new flag to test error recovery without error injection so we can test the path where error recovery actually succeeds
- Some Refactory & fix to db stress test framework (see PR review comments)
- Fix some minor bugs surfaced (see PR review comments)
- Limitation: had to disable backup restore with metadata read/write injection since it surfaces too many testing issues. Will add it back later to focus on surfacing actual code/internal bugs first.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12713
Test Plan:
- Existing UT
- CI with no trivial error failure
Reviewed By: pdillinger
Differential Revision: D58326608
Pulled By: hx235
fbshipit-source-id: 011b5195aaeb6011641ae0a9194f7f2a0e325ad7
2024-06-19 15:42:00 +00:00
|
|
|
DEFINE_bool(error_recovery_with_no_fault_injection, false,
|
|
|
|
"If true, error recovery will be done without fault injection if "
|
|
|
|
"fault injection is enabled");
|
|
|
|
|
|
|
|
DEFINE_int32(metadata_read_fault_one_in, 1000,
|
|
|
|
"On non-zero, enables fault injection on metadata read (i.e, "
|
|
|
|
"directory and file metadata read)");
|
|
|
|
|
2020-07-14 19:10:56 +00:00
|
|
|
DEFINE_int32(get_property_one_in, 1000,
|
|
|
|
"If non-zero, then DB::GetProperty() will be called to get various"
|
|
|
|
" properties for every N ops on average. 0 indicates that"
|
|
|
|
" GetProperty() will be not be called.");
|
|
|
|
|
2024-04-16 22:43:26 +00:00
|
|
|
DEFINE_int32(get_properties_of_all_tables_one_in, 1000,
|
|
|
|
"If non-zero, then DB::GetPropertiesOfAllTables() will be called "
|
|
|
|
"for every N ops on average. 0 indicates that"
|
|
|
|
" it will be not be called.");
|
|
|
|
|
2020-04-16 18:10:53 +00:00
|
|
|
DEFINE_bool(sync_fault_injection, false,
|
|
|
|
"If true, FaultInjectionTestFS will be used for write operations, "
|
2021-12-07 21:40:46 +00:00
|
|
|
"and unsynced data in DB will lost after crash. In such a case we "
|
|
|
|
"track DB changes in a trace file (\"*.trace\") in "
|
|
|
|
"--expected_values_dir for verifying there are no holes in the "
|
2021-12-15 20:53:32 +00:00
|
|
|
"recovered data.");
|
2020-06-13 02:24:11 +00:00
|
|
|
|
|
|
|
DEFINE_bool(best_efforts_recovery, false,
|
|
|
|
"If true, use best efforts recovery.");
|
Add Iterator test against expected state to stress test (#10538)
Summary:
As mentioned in https://github.com/facebook/rocksdb/pull/5506#issuecomment-506021913,
`db_stress` does not have much verification for iterator correctness.
It has a `TestIterate()` function, but that is mainly for comparing results
between two iterators, one with `total_order_seek` and the other optionally
sets auto_prefix, upper/lower bounds. Commit 49a0581ad2462e31aa3f768afa769e0d33390f33
added a new `TestIterateAgainstExpected()` function that compares iterator against
expected state. It locks a range of keys, creates an iterator, does
a random sequence of `Next/Prev` and compares against expected state.
This PR is based on that commit, the main changes include some logs
(for easier debugging if a test fails), a forward and backward scan to
cover the entire locked key range, and a flag for optionally turning on
this version of Iterator testing.
Added constraint that the checks against expected state in
`TestIterateAgainstExpected()` and in `TestGet()` are only turned on
when `--skip_verifydb` flag is not set.
Remove the change log introduced in https://github.com/facebook/rocksdb/issues/10553.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/10538
Test Plan:
Run `db_stress` with `--verify_iterator_with_expected_state_one_in=1`,
and a large `--iterpercent` and `--num_iterations`. Checked `op_logs`
manually to ensure expected coverage. Tweaked part of the code in
https://github.com/facebook/rocksdb/issues/10449 and stress test was able to catch it.
- internally run various flavor of crash test
Reviewed By: ajkr
Differential Revision: D38847269
Pulled By: cbi42
fbshipit-source-id: 8b4402a9bba9f6cfa08051943cd672579d489599
2022-08-24 21:59:50 +00:00
|
|
|
DEFINE_bool(skip_verifydb, false,
|
|
|
|
"If true, skip VerifyDb() calls and Get()/Iterator verifications"
|
|
|
|
"against expected state.");
|
2020-06-18 16:51:14 +00:00
|
|
|
|
|
|
|
DEFINE_bool(enable_compaction_filter, false,
|
|
|
|
"If true, configures a compaction filter that returns a kRemove "
|
|
|
|
"decision for deleted keys.");
|
|
|
|
|
2020-09-30 21:39:47 +00:00
|
|
|
DEFINE_bool(paranoid_file_checks, true,
|
|
|
|
"After writing every SST file, reopen it and read all the keys "
|
|
|
|
"and validate checksums");
|
|
|
|
|
2021-05-05 19:53:42 +00:00
|
|
|
DEFINE_bool(fail_if_options_file_error, false,
|
|
|
|
"Fail operations that fail to detect or properly persist options "
|
|
|
|
"file.");
|
|
|
|
|
Integrity protection for live updates to WriteBatch (#7748)
Summary:
This PR adds the foundation classes for key-value integrity protection and the first use case: protecting live updates from the source buffers added to `WriteBatch` through the destination buffer in `MemTable`. The width of the protection info is not yet configurable -- only eight bytes per key is supported. This PR allows users to enable protection by constructing `WriteBatch` with `protection_bytes_per_key == 8`. It does not yet expose a way for users to get integrity protection via other write APIs (e.g., `Put()`, `Merge()`, `Delete()`, etc.).
The foundation classes (`ProtectionInfo.*`) embed the coverage info in their type, and provide `Protect.*()` and `Strip.*()` functions to navigate between types with different coverage. For making bytes per key configurable (for powers of two up to eight) in the future, these classes are templated on the unsigned integer type used to store the protection info. That integer contains the XOR'd result of hashes with independent seeds for all covered fields. For integer fields, the hash is computed on the raw unadjusted bytes, so the result is endian-dependent. The most significant bytes are truncated when the hash value (8 bytes) is wider than the protection integer.
When `WriteBatch` is constructed with `protection_bytes_per_key == 8`, we hold a `ProtectionInfoKVOTC` (i.e., one that covers key, value, optype aka `ValueType`, timestamp, and CF ID) for each entry added to the batch. The protection info is generated from the original buffers passed by the user, as well as the original metadata generated internally. When writing to memtable, each entry is transformed to a `ProtectionInfoKVOTS` (i.e., dropping coverage of CF ID and adding coverage of sequence number), since at that point we know the sequence number, and have already selected a memtable corresponding to a particular CF. This protection info is verified once the entry is encoded in the `MemTable` buffer.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/7748
Test Plan:
- an integration test to verify a wide variety of single-byte changes to the encoded `MemTable` buffer are caught
- add to stress/crash test to verify it works in variety of configs/operations without intentional corruption
- [deferred] unit tests for `ProtectionInfo.*` classes for edge cases like KV swap, `SliceParts` and `Slice` APIs are interchangeable, etc.
Reviewed By: pdillinger
Differential Revision: D25754492
Pulled By: ajkr
fbshipit-source-id: e481bac6c03c2ab268be41359730f1ceb9964866
2021-01-29 20:17:17 +00:00
|
|
|
DEFINE_uint64(batch_protection_bytes_per_key, 0,
|
|
|
|
"If nonzero, enables integrity protection in `WriteBatch` at the "
|
|
|
|
"specified number of bytes per key. Currently the only supported "
|
|
|
|
"nonzero value is eight.");
|
|
|
|
|
2022-08-12 20:51:32 +00:00
|
|
|
DEFINE_uint32(
|
|
|
|
memtable_protection_bytes_per_key, 0,
|
|
|
|
"If nonzero, enables integrity protection in memtable entries at the "
|
|
|
|
"specified number of bytes per key. Currently the supported "
|
|
|
|
"nonzero values are 1, 2, 4 and 8.");
|
|
|
|
|
2023-04-25 19:08:23 +00:00
|
|
|
DEFINE_uint32(block_protection_bytes_per_key, 0,
|
|
|
|
"If nonzero, enables integrity protection in blocks at the "
|
|
|
|
"specified number of bytes per key. Currently the supported "
|
|
|
|
"nonzero values are 1, 2, 4 and 8.");
|
|
|
|
|
2020-09-04 06:49:27 +00:00
|
|
|
DEFINE_string(file_checksum_impl, "none",
|
|
|
|
"Name of an implementation for file_checksum_gen_factory, or "
|
|
|
|
"\"none\" for null.");
|
|
|
|
|
2020-12-17 19:51:04 +00:00
|
|
|
DEFINE_int32(write_fault_one_in, 0,
|
2023-09-18 23:23:26 +00:00
|
|
|
"On non-zero, enables fault injection on write. Currently only"
|
|
|
|
"injects write error when writing to SST files.");
|
2020-12-17 19:51:04 +00:00
|
|
|
|
Decouple sync fault and write injection in FaultInjectionTestFS & fix tracing issue under WAL write error injection (#12797)
Summary:
**Context/Summary:**
After injecting write error to WAL, we started to see crash recovery verification failure in prefix recovery. That's because the current tracing implementation traces every write before it writes to WAL even when the WAL write can fail with write error injection. One consequence of that is the traced writes in trace files does not corresponding to write sequence sequence anymore e.g, it has more traced writes that the actual assigned sequence number to successful writes. Therefore https://github.com/facebook/rocksdb/blob/b4a84efb4e842b782e976de5b22a4554c2f76edd/db_stress_tool/expected_state.cc#L674 won't restore the ExpectedState to the correct sequence number we want.
Ideally, we should have a prepare-commit mechanism for tracing just like our ExpectedState so we can ignore the traced write if the write fails later. But for now, to simplify, we simply don't inject WAL error (and metadata write error cuz it could fail write when sync WAL dir fails)
To do so, we need to be able to exclude WAL from write injection but still allow sync fault injection in it to maintain its original sync fault testing coverage. This prompts us to decouple sync fault and write injection in FaultInjectionTestFS. And this is what this PR mainly about.
So now `FaultInjectionTestFS` works as the following:
- If direct_writable is true, then `FaultInjectionTestFS` is bypassed for writable file
- Otherwise, FaultInjectionTestFS` can buffer data for sync fault injection (if inject_unsynced_data_loss_ == true, global settings) and/or inject write error (if MaybeInjectThreadLocalError(), thread-local settings). WAL file can be optionally excluded from write injection
Bonus: better naming of relevant variables
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12797
Test Plan:
- The follow commands failed before this fix but passes after
```
python3 tools/db_crashtest.py --simple blackbox \
--interval=5 \
--preserve_unverified_changes=1 \
--threads=32 \
--disable_auto_compactions=1 \
--WAL_size_limit_MB=0 --WAL_ttl_seconds=0 --acquire_snapshot_one_in=0 --adaptive_readahead=0 --adm_policy=0 --advise_random_on_open=1 --allow_concurrent_memtable_write=0 --allow_data_in_errors=True --allow_fallocate=1 --async_io=0 --auto_readahead_size=0 --avoid_flush_during_recovery=1 --avoid_flush_during_shutdown=0 --avoid_unnecessary_blocking_io=0 --backup_max_size=104857600 --backup_one_in=0 --batch_protection_bytes_per_key=0 --bgerror_resume_retry_interval=1000000 --block_align=0 --block_protection_bytes_per_key=4 --block_size=16384 --bloom_before_level=2147483646 --bloom_bits=3.2003682301518492 --bottommost_compression_type=zlib --bottommost_file_compaction_delay=600 --bytes_per_sync=0 --cache_index_and_filter_blocks=1 --cache_index_and_filter_blocks_with_high_priority=1 --cache_size=33554432 --cache_type=fixed_hyper_clock_cache --charge_compression_dictionary_building_buffer=0 --charge_file_metadata=0 --charge_filter_construction=0 --charge_table_reader=1 --check_multiget_consistency=0 --check_multiget_entity_consistency=0 --checkpoint_one_in=0 --checksum_type=kxxHash64 --clear_column_family_one_in=0 --column_families=1 --compact_files_one_in=0 --compact_range_one_in=0 --compaction_pri=2 --compaction_readahead_size=0 --compaction_ttl=0 --compress_format_version=1 --compressed_secondary_cache_size=16777216 --compression_checksum=1 --compression_max_dict_buffer_bytes=549755813887 --compression_max_dict_bytes=16384 --compression_parallel_threads=1 --compression_type=none --compression_use_zstd_dict_trainer=1 --compression_zstd_max_train_bytes=0 --continuous_verification_interval=0 --daily_offpeak_time_utc=00:00-23:59 --data_block_index_type=0 \
--db_write_buffer_size=0 --delete_obsolete_files_period_micros=0 --delpercent=0 --delrangepercent=0 --destroy_db_initially=0 --detect_filter_construct_corruption=0 --disable_file_deletions_one_in=0 --disable_manual_compaction_one_in=0 --disable_wal=0 --dump_malloc_stats=0 --enable_checksum_handoff=0 --enable_compaction_filter=0 --enable_custom_split_merge=0 --enable_do_not_compress_roles=1 --enable_index_compression=0 --enable_memtable_insert_with_hint_prefix_extractor=0 --enable_pipelined_write=0 --enable_sst_partitioner_factory=0 --enable_thread_tracking=0 --enable_write_thread_adaptive_yield=0 --error_recovery_with_no_fault_injection=0 --fail_if_options_file_error=0 --fifo_allow_compaction=1 --file_checksum_impl=xxh64 --fill_cache=0 --flush_one_in=100 --format_version=4 --get_all_column_family_metadata_one_in=0 --get_current_wal_file_one_in=0 --get_live_files_apis_one_in=0 --get_properties_of_all_tables_one_in=0 --get_property_one_in=0 --get_sorted_wal_files_one_in=0 --hard_pending_compaction_bytes_limit=274877906944 --high_pri_pool_ratio=0.5 --index_block_restart_interval=9 --index_shortening=1 --index_type=0 --ingest_external_file_one_in=0 --initial_auto_readahead_size=0 --inplace_update_support=0 --iterpercent=0 --key_len_percent_dist=1,30,69 --key_may_exist_one_in=0 --last_level_temperature=kUnknown --level_compaction_dynamic_level_bytes=1 --lock_wal_one_in=0 --log2_keys_per_lock=10 --log_file_time_to_roll=0 --log_readahead_size=16777216 --long_running_snapshots=0 --low_pri_pool_ratio=0 --lowest_used_cache_tier=2 --manifest_preallocation_size=0 --manual_wal_flush_one_in=0 --mark_for_compaction_one_file_in=0 --max_auto_readahead_size=524288 --max_background_compactions=1 --max_bytes_for_level_base=67108864 --max_key=1000 --max_key_len=3 --memtable_insert_hint_per_batch=0 --memtable_max_range_deletions=0 --memtable_prefix_bloom_size_ratio=0.5 --memtable_protection_bytes_per_key=8 --memtable_whole_key_filtering=0 --memtablerep=skip_list --metadata_charge_policy=0 --metadata_read_fault_one_in=0 --metadata_write_fault_one_in=0 --min_write_buffer_number_to_merge=1 --mmap_read=0 --mock_direct_io=False --nooverwritepercent=1 --num_file_reads_for_auto_readahead=0 --open_files=-1 --open_metadata_read_fault_one_in=0 --open_metadata_write_fault_one_in=0 --open_read_fault_one_in=0 --open_write_fault_one_in=0 --ops_per_thread=20000000 \
--optimize_filters_for_hits=1 --optimize_filters_for_memory=1 --optimize_multiget_for_io=0 --paranoid_file_checks=1 --partition_filters=0 --partition_pinning=3 --pause_background_one_in=0 --periodic_compaction_seconds=0 --prefix_size=1 --prefixpercent=0 --prepopulate_block_cache=0 --preserve_internal_time_seconds=0 --progress_reports=0 --promote_l0_one_in=0 --read_amp_bytes_per_bit=0 --read_fault_one_in=0 --readahead_size=0 --readpercent=0 --recycle_log_file_num=0 --reopen=0 --report_bg_io_stats=0 --reset_stats_one_in=1000000 --sample_for_compression=5 --secondary_cache_fault_one_in=0 --secondary_cache_uri= --skip_stats_update_on_db_open=0 --snapshot_hold_ops=100000 --soft_pending_compaction_bytes_limit=68719476736 --sqfc_name=bar --sqfc_version=1 --sst_file_manager_bytes_per_sec=0 --sst_file_manager_bytes_per_truncate=0 --stats_dump_period_sec=10 --stats_history_buffer_size=0 --strict_bytes_per_sync=0 --subcompactions=1 --sync=0 --sync_fault_injection=1 --table_cache_numshardbits=0 --target_file_size_base=16777216 --target_file_size_multiplier=1 --test_batches_snapshots=0 --top_level_index_pinning=3 --uncache_aggressiveness=9890 --universal_max_read_amp=-1 --unpartitioned_pinning=3 --use_adaptive_mutex=0 --use_adaptive_mutex_lru=1 --use_attribute_group=0 --use_delta_encoding=0 --use_direct_io_for_flush_and_compaction=0 --use_direct_reads=0 --use_full_merge_v1=0 --use_get_entity=0 --use_merge=0 --use_multi_cf_iterator=0 --use_multi_get_entity=0 --use_multiget=0 --use_put_entity_one_in=0 --use_sqfc_for_range_queries=0 --use_timed_put_one_in=0 --use_write_buffer_manager=0 --user_timestamp_size=0 --value_size_mult=32 --verification_only=0 --verify_checksum=0 --verify_checksum_one_in=0 --verify_compression=1 --verify_db_one_in=0 --verify_file_checksums_one_in=0 --verify_iterator_with_expected_state_one_in=5 --verify_sst_unique_id_in_manifest=1 --wal_bytes_per_sync=0 --wal_compression=zstd --write_buffer_size=335544320 --write_dbid_to_manifest=1 --write_fault_one_in=100 --writepercent=100
```
- CI
Reviewed By: cbi42
Differential Revision: D58917145
Pulled By: hx235
fbshipit-source-id: b6397036bea035a92341c2b05fb01872db2153d7
2024-06-26 21:56:35 +00:00
|
|
|
DEFINE_bool(exclude_wal_from_write_fault_injection, false,
|
|
|
|
"If true, we won't inject write fault when writing to WAL file");
|
|
|
|
|
Inject more errors to more files in stress test (#12713)
Summary:
**Context:**
We currently have partial error injection:
- DB operation: all read, SST write
- DB open: all read, SST write, all metadata write.
This PR completes the error injection (with some limitations below):
- DB operation & open: all read, all write, all metadata write, all metadata read
**Summary:**
- Inject retryable metadata read, metadata write error concerning directory (e.g, dir sync, ) or file metadata (e.g, name, size, file creation/deletion...)
- Inject retryable errors to all major file types: random access file, sequential file, writable file
- Allow db stress test operations to handle above injected errors gracefully without crashing
- Change all error injection to thread-local implementation for easier disabling and enabling in the same thread. For example, we can control error handling thread to have no error injection. It's also cleaner in code.
- Limitation: compared to before, we now don't have write fault injection for backup/restore CopyOrCreateFiles work threads since they use anonymous background threads as well as read injection for db open bg thread
- Add a new flag to test error recovery without error injection so we can test the path where error recovery actually succeeds
- Some Refactory & fix to db stress test framework (see PR review comments)
- Fix some minor bugs surfaced (see PR review comments)
- Limitation: had to disable backup restore with metadata read/write injection since it surfaces too many testing issues. Will add it back later to focus on surfacing actual code/internal bugs first.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12713
Test Plan:
- Existing UT
- CI with no trivial error failure
Reviewed By: pdillinger
Differential Revision: D58326608
Pulled By: hx235
fbshipit-source-id: 011b5195aaeb6011641ae0a9194f7f2a0e325ad7
2024-06-19 15:42:00 +00:00
|
|
|
DEFINE_int32(metadata_write_fault_one_in, 1000,
|
|
|
|
"On non-zero, enables fault injection on metadata write (i.e, "
|
|
|
|
"directory and file metadata write)");
|
|
|
|
|
Add user-defined timestamps to db_stress (#8061)
Summary:
Add some basic test for user-defined timestamp to db_stress. Currently,
read with timestamp always tries to read using the current timestamp.
Due to the per-key timestamp-sequence ordering constraint, we only add timestamp-
related tests to the `NonBatchedOpsStressTest` since this test serializes accesses
to the same key and uses a file to cross-check data correctness.
The timestamp feature is not supported in a number of components, e.g. Merge, SingleDelete,
DeleteRange, CompactionFilter, Readonly instance, secondary instance, SST file ingestion, transaction,
etc. Therefore, db_stress should exit if user enables both timestamp and these features at the same
time. The (currently) incompatible features can be found in
`CheckAndSetOptionsForUserTimestamp`.
This PR also fixes a bug triggered when timestamp is enabled together with
`index_type=kBinarySearchWithFirstKey`. This bug fix will also be in another separate PR
with more unit tests coverage. Fixing it here because I do not want to exclude the index type
from crash test.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/8061
Test Plan: make crash_test_with_ts
Reviewed By: jay-zhuang
Differential Revision: D27056282
Pulled By: riversand963
fbshipit-source-id: c3e00ad1023fdb9ebbdf9601ec18270c5e2925a9
2021-03-23 12:12:04 +00:00
|
|
|
DEFINE_uint64(user_timestamp_size, 0,
|
|
|
|
"Number of bytes for a user-defined timestamp. Currently, only "
|
|
|
|
"8-byte is supported");
|
|
|
|
|
2023-12-12 17:35:29 +00:00
|
|
|
DEFINE_bool(persist_user_defined_timestamps, true,
|
|
|
|
"Flag to indicate whether user-defined timestamps will be persisted"
|
|
|
|
" during Flush");
|
|
|
|
|
Inject more errors to more files in stress test (#12713)
Summary:
**Context:**
We currently have partial error injection:
- DB operation: all read, SST write
- DB open: all read, SST write, all metadata write.
This PR completes the error injection (with some limitations below):
- DB operation & open: all read, all write, all metadata write, all metadata read
**Summary:**
- Inject retryable metadata read, metadata write error concerning directory (e.g, dir sync, ) or file metadata (e.g, name, size, file creation/deletion...)
- Inject retryable errors to all major file types: random access file, sequential file, writable file
- Allow db stress test operations to handle above injected errors gracefully without crashing
- Change all error injection to thread-local implementation for easier disabling and enabling in the same thread. For example, we can control error handling thread to have no error injection. It's also cleaner in code.
- Limitation: compared to before, we now don't have write fault injection for backup/restore CopyOrCreateFiles work threads since they use anonymous background threads as well as read injection for db open bg thread
- Add a new flag to test error recovery without error injection so we can test the path where error recovery actually succeeds
- Some Refactory & fix to db stress test framework (see PR review comments)
- Fix some minor bugs surfaced (see PR review comments)
- Limitation: had to disable backup restore with metadata read/write injection since it surfaces too many testing issues. Will add it back later to focus on surfacing actual code/internal bugs first.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12713
Test Plan:
- Existing UT
- CI with no trivial error failure
Reviewed By: pdillinger
Differential Revision: D58326608
Pulled By: hx235
fbshipit-source-id: 011b5195aaeb6011641ae0a9194f7f2a0e325ad7
2024-06-19 15:42:00 +00:00
|
|
|
DEFINE_int32(open_metadata_read_fault_one_in, 0,
|
|
|
|
"On non-zero, enables fault injection on file metadata read (i.e, "
|
|
|
|
"directory and file metadata read)"
|
|
|
|
"during DB reopen.");
|
|
|
|
|
2021-04-28 17:57:11 +00:00
|
|
|
DEFINE_int32(open_metadata_write_fault_one_in, 0,
|
|
|
|
"On non-zero, enables fault injection on file metadata write "
|
|
|
|
"during DB reopen.");
|
|
|
|
|
2021-06-28 06:53:47 +00:00
|
|
|
DEFINE_string(secondary_cache_uri, "",
|
|
|
|
"Full URI for creating a customized secondary cache object");
|
2021-11-08 18:26:48 +00:00
|
|
|
DEFINE_int32(secondary_cache_fault_one_in, 0,
|
|
|
|
"On non-zero, enables fault injection in secondary cache inserts"
|
|
|
|
" and lookups");
|
2023-10-10 20:12:18 +00:00
|
|
|
DEFINE_double(tiered_cache_percent_compressed, 0.0,
|
|
|
|
"Percentage of total block cache budget to allocate to the "
|
|
|
|
"compressed cache");
|
2021-06-30 23:45:44 +00:00
|
|
|
DEFINE_int32(open_write_fault_one_in, 0,
|
2021-07-06 18:04:04 +00:00
|
|
|
"On non-zero, enables fault injection on file writes "
|
|
|
|
"during DB reopen.");
|
|
|
|
DEFINE_int32(open_read_fault_one_in, 0,
|
|
|
|
"On non-zero, enables fault injection on file reads "
|
2021-06-30 23:45:44 +00:00
|
|
|
"during DB reopen.");
|
2023-09-05 17:41:29 +00:00
|
|
|
DEFINE_int32(inject_error_severity, 1,
|
|
|
|
"The severity of the injected IO Error. 1 is soft error (e.g. "
|
2021-07-01 21:15:49 +00:00
|
|
|
"retryable error), 2 is fatal error, and the default is "
|
|
|
|
"retryable error.");
|
2021-12-08 20:43:09 +00:00
|
|
|
DEFINE_int32(prepopulate_block_cache,
|
|
|
|
static_cast<int32_t>(ROCKSDB_NAMESPACE::BlockBasedTableOptions::
|
|
|
|
PrepopulateBlockCache::kDisable),
|
|
|
|
"Options related to cache warming (see `enum "
|
|
|
|
"PrepopulateBlockCache` in table.h)");
|
2021-06-28 06:53:47 +00:00
|
|
|
|
2022-03-17 02:00:04 +00:00
|
|
|
DEFINE_bool(two_write_queues, false,
|
|
|
|
"Set to true to enable two write queues. Default: false");
|
|
|
|
|
|
|
|
DEFINE_bool(use_only_the_last_commit_time_batch_for_recovery, false,
|
|
|
|
"If true, the commit-time write batch will not be immediately "
|
|
|
|
"inserted into the memtables. Default: false");
|
|
|
|
|
|
|
|
DEFINE_uint64(
|
|
|
|
wp_snapshot_cache_bits, 7ull,
|
|
|
|
"Number of bits to represent write-prepared transaction db's snapshot "
|
|
|
|
"cache. Default: 7 (128 entries)");
|
|
|
|
|
|
|
|
DEFINE_uint64(wp_commit_cache_bits, 23ull,
|
|
|
|
"Number of bits to represent write-prepared transaction db's "
|
|
|
|
"commit cache. Default: 23 (8M entries)");
|
|
|
|
|
2022-03-30 20:52:37 +00:00
|
|
|
DEFINE_bool(adaptive_readahead, false,
|
|
|
|
"Carry forward internal auto readahead size from one file to next "
|
|
|
|
"file at each level during iteration");
|
|
|
|
DEFINE_bool(
|
|
|
|
async_io, false,
|
|
|
|
"Does asynchronous prefetching when internal auto readahead is enabled");
|
|
|
|
|
2022-04-06 22:47:09 +00:00
|
|
|
DEFINE_string(wal_compression, "none",
|
|
|
|
"Algorithm to use for WAL compression. none to disable.");
|
|
|
|
|
2022-05-19 18:04:21 +00:00
|
|
|
DEFINE_bool(
|
|
|
|
verify_sst_unique_id_in_manifest, false,
|
|
|
|
"Enable DB options `verify_sst_unique_id_in_manifest`, if true, during "
|
|
|
|
"DB-open try verifying the SST unique id between MANIFEST and SST "
|
|
|
|
"properties.");
|
|
|
|
|
Snapshots with user-specified timestamps (#9879)
Summary:
In RocksDB, keys are associated with (internal) sequence numbers which denote when the keys are written
to the database. Sequence numbers in different RocksDB instances are unrelated, thus not comparable.
It is nice if we can associate sequence numbers with their corresponding actual timestamps. One thing we can
do is to support user-defined timestamp, which allows the applications to specify the format of custom timestamps
and encode a timestamp with each key. More details can be found at https://github.com/facebook/rocksdb/wiki/User-defined-Timestamp-%28Experimental%29.
This PR provides a different but complementary approach. We can associate rocksdb snapshots (defined in
https://github.com/facebook/rocksdb/blob/7.2.fb/include/rocksdb/snapshot.h#L20) with **user-specified** timestamps.
Since a snapshot is essentially an object representing a sequence number, this PR establishes a bi-directional mapping between sequence numbers and timestamps.
In the past, snapshots are usually taken by readers. The current super-version is grabbed, and a `rocksdb::Snapshot`
object is created with the last published sequence number of the super-version. You can see that the reader actually
has no good idea of what timestamp to assign to this snapshot, because by the time the `GetSnapshot()` is called,
an arbitrarily long period of time may have already elapsed since the last write, which is when the last published
sequence number is written.
This observation motivates the creation of "timestamped" snapshots on the write path. Currently, this functionality is
exposed only to the layer of `TransactionDB`. Application can tell RocksDB to create a snapshot when a transaction
commits, effectively associating the last sequence number with a timestamp. It is also assumed that application will
ensure any two snapshots with timestamps should satisfy the following:
```
snapshot1.seq < snapshot2.seq iff. snapshot1.ts < snapshot2.ts
```
If the application can guarantee that when a reader takes a timestamped snapshot, there is no active writes going on
in the database, then we also allow the user to use a new API `TransactionDB::CreateTimestampedSnapshot()` to create
a snapshot with associated timestamp.
Code example
```cpp
// Create a timestamped snapshot when committing transaction.
txn->SetCommitTimestamp(100);
txn->SetSnapshotOnNextOperation();
txn->Commit();
// A wrapper API for convenience
Status Transaction::CommitAndTryCreateSnapshot(
std::shared_ptr<TransactionNotifier> notifier,
TxnTimestamp ts,
std::shared_ptr<const Snapshot>* ret);
// Create a timestamped snapshot if caller guarantees no concurrent writes
std::pair<Status, std::shared_ptr<const Snapshot>> snapshot = txn_db->CreateTimestampedSnapshot(100);
```
The snapshots created in this way will be managed by RocksDB with ref-counting and potentially shared with
other readers. We provide the following APIs for readers to retrieve a snapshot given a timestamp.
```cpp
// Return the timestamped snapshot correponding to given timestamp. If ts is
// kMaxTxnTimestamp, then we return the latest timestamped snapshot if present.
// Othersise, we return the snapshot whose timestamp is equal to `ts`. If no
// such snapshot exists, then we return null.
std::shared_ptr<const Snapshot> TransactionDB::GetTimestampedSnapshot(TxnTimestamp ts) const;
// Return the latest timestamped snapshot if present.
std::shared_ptr<const Snapshot> TransactionDB::GetLatestTimestampedSnapshot() const;
```
We also provide two additional APIs for stats collection and reporting purposes.
```cpp
Status TransactionDB::GetAllTimestampedSnapshots(
std::vector<std::shared_ptr<const Snapshot>>& snapshots) const;
// Return timestamped snapshots whose timestamps fall in [ts_lb, ts_ub) and store them in `snapshots`.
Status TransactionDB::GetTimestampedSnapshots(
TxnTimestamp ts_lb,
TxnTimestamp ts_ub,
std::vector<std::shared_ptr<const Snapshot>>& snapshots) const;
```
To prevent the number of timestamped snapshots from growing infinitely, we provide the following API to release
timestamped snapshots whose timestamps are older than or equal to a given threshold.
```cpp
void TransactionDB::ReleaseTimestampedSnapshotsOlderThan(TxnTimestamp ts);
```
Before shutdown, RocksDB will release all timestamped snapshots.
Comparison with user-defined timestamp and how they can be combined:
User-defined timestamp persists every key with a timestamp, while timestamped snapshots maintain a volatile
mapping between snapshots (sequence numbers) and timestamps.
Different internal keys with the same user key but different timestamps will be treated as different by compaction,
thus a newer version will not hide older versions (with smaller timestamps) unless they are eligible for garbage collection.
In contrast, taking a timestamped snapshot at a certain sequence number and timestamp prevents all the keys visible in
this snapshot from been dropped by compaction. Here, visible means (seq < snapshot and most recent).
The timestamped snapshot supports the semantics of reading at an exact point in time.
Timestamped snapshots can also be used with user-defined timestamp.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9879
Test Plan:
```
make check
TEST_TMPDIR=/dev/shm make crash_test_with_txn
```
Reviewed By: siying
Differential Revision: D35783919
Pulled By: riversand963
fbshipit-source-id: 586ad905e169189e19d3bfc0cb0177a7239d1bd4
2022-06-10 23:07:03 +00:00
|
|
|
DEFINE_int32(
|
|
|
|
create_timestamped_snapshot_one_in, 0,
|
|
|
|
"On non-zero, create timestamped snapshots upon transaction commits.");
|
|
|
|
|
2022-06-15 19:38:04 +00:00
|
|
|
DEFINE_bool(allow_data_in_errors,
|
|
|
|
ROCKSDB_NAMESPACE::Options().allow_data_in_errors,
|
|
|
|
"If true, allow logging data, e.g. key, value in LOG files.");
|
|
|
|
|
2023-04-21 16:07:18 +00:00
|
|
|
DEFINE_bool(enable_thread_tracking,
|
|
|
|
ROCKSDB_NAMESPACE::Options().enable_thread_tracking,
|
|
|
|
"If true, the status of the threads involved in this DB will be "
|
|
|
|
"tracked and available via GetThreadList() API.");
|
|
|
|
|
Add Iterator test against expected state to stress test (#10538)
Summary:
As mentioned in https://github.com/facebook/rocksdb/pull/5506#issuecomment-506021913,
`db_stress` does not have much verification for iterator correctness.
It has a `TestIterate()` function, but that is mainly for comparing results
between two iterators, one with `total_order_seek` and the other optionally
sets auto_prefix, upper/lower bounds. Commit 49a0581ad2462e31aa3f768afa769e0d33390f33
added a new `TestIterateAgainstExpected()` function that compares iterator against
expected state. It locks a range of keys, creates an iterator, does
a random sequence of `Next/Prev` and compares against expected state.
This PR is based on that commit, the main changes include some logs
(for easier debugging if a test fails), a forward and backward scan to
cover the entire locked key range, and a flag for optionally turning on
this version of Iterator testing.
Added constraint that the checks against expected state in
`TestIterateAgainstExpected()` and in `TestGet()` are only turned on
when `--skip_verifydb` flag is not set.
Remove the change log introduced in https://github.com/facebook/rocksdb/issues/10553.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/10538
Test Plan:
Run `db_stress` with `--verify_iterator_with_expected_state_one_in=1`,
and a large `--iterpercent` and `--num_iterations`. Checked `op_logs`
manually to ensure expected coverage. Tweaked part of the code in
https://github.com/facebook/rocksdb/issues/10449 and stress test was able to catch it.
- internally run various flavor of crash test
Reviewed By: ajkr
Differential Revision: D38847269
Pulled By: cbi42
fbshipit-source-id: 8b4402a9bba9f6cfa08051943cd672579d489599
2022-08-24 21:59:50 +00:00
|
|
|
DEFINE_int32(verify_iterator_with_expected_state_one_in, 0,
|
|
|
|
"If non-zero, when TestIterate() is to be called, there is a "
|
|
|
|
"1/verify_iterator_with_expected_state_one_in "
|
|
|
|
"chance that the iterator is verified against the expected state "
|
|
|
|
"file, instead of comparing keys between two iterators.");
|
|
|
|
|
2022-09-09 19:52:27 +00:00
|
|
|
DEFINE_uint64(readahead_size, 0, "Iterator readahead size");
|
|
|
|
DEFINE_uint64(initial_auto_readahead_size, 0,
|
|
|
|
"Initial auto readahead size for prefetching during Iteration");
|
|
|
|
DEFINE_uint64(max_auto_readahead_size, 0,
|
|
|
|
"Max auto readahead size for prefetching during Iteration");
|
|
|
|
DEFINE_uint64(
|
|
|
|
num_file_reads_for_auto_readahead, 0,
|
|
|
|
"Num of sequential reads to enable auto prefetching during Iteration");
|
|
|
|
|
db_stress option to preserve all files until verification success (#10659)
Summary:
In `db_stress`, DB and expected state files containing changes leading up to a verification failure are often deleted, which makes debugging such failures difficult. On the DB side, flushed WAL files and compacted SST files are marked obsolete and then deleted. Without those files, we cannot pinpoint where a key that failed verification changed unexpectedly. On the expected state side, files for verifying prefix-recoverability in the presence of unsynced data loss are deleted before verification. These include a baseline state file containing the expected state at the time of the last successful verification, and a trace file containing all operations since then. Without those files, we cannot know the sequence of DB operations expected to be recovered.
This PR attempts to address this gap with a new `db_stress` flag: `preserve_unverified_changes`. Setting `preserve_unverified_changes=1` has two effects.
First, prior to startup verification, `db_stress` hardlinks all DB and expected state files in "unverified/" subdirectories of `FLAGS_db` and `FLAGS_expected_values_dir`. The separate directories are needed because the pre-verification opening process deletes files written by the previous `db_stress` run as described above. These "unverified/" subdirectories are cleaned up following startup verification success.
I considered other approaches for preserving DB files through startup verification, like using a read-only DB or preventing deletion of DB files externally, e.g., in the `Env` layer. However, I decided against it since such an approach would not work for expected state files, and I did not want to change the DB management logic. If there were a way to disable DB file deletions before regular DB open, I would have preferred to use that.
Second, `db_stress` attempts to keep all DB and expected state files that were live at some point since the start of the `db_stress` run. This is a bit tricky and involves the following changes.
- Open the DB with `disable_auto_compactions=1` and `avoid_flush_during_recovery=1`
- DisableFileDeletions()
- EnableAutoCompactions()
For this part, too, I would have preferred to use a hypothetical API that disables DB file deletion before regular DB open.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/10659
Reviewed By: hx235
Differential Revision: D39407454
Pulled By: ajkr
fbshipit-source-id: 6e981025c7dce147649d2e770728471395a7fa53
2022-09-12 21:49:38 +00:00
|
|
|
DEFINE_bool(
|
|
|
|
preserve_unverified_changes, false,
|
|
|
|
"DB files of the current run will all be preserved in `FLAGS_db`. DB files "
|
|
|
|
"from the last run will be preserved in `FLAGS_db/unverified` until the "
|
|
|
|
"first verification succeeds. Expected state files from the last run will "
|
|
|
|
"be preserved similarly under `FLAGS_expected_values_dir/unverified` when "
|
|
|
|
"`--expected_values_dir` is nonempty.");
|
|
|
|
|
2022-10-06 21:54:21 +00:00
|
|
|
DEFINE_uint64(stats_dump_period_sec,
|
|
|
|
ROCKSDB_NAMESPACE::Options().stats_dump_period_sec,
|
|
|
|
"Gap between printing stats to log in seconds");
|
|
|
|
|
2023-08-23 22:24:23 +00:00
|
|
|
DEFINE_bool(verification_only, false,
|
|
|
|
"If true, tests will only execute verification step");
|
2024-01-31 20:37:42 +00:00
|
|
|
extern "C" bool RocksDbIOUringEnable() { return true; }
|
2023-02-17 02:33:06 +00:00
|
|
|
|
2023-08-03 02:58:56 +00:00
|
|
|
DEFINE_uint32(memtable_max_range_deletions, 0,
|
|
|
|
"If nonzero, RocksDB will try to flush the current memtable"
|
|
|
|
"after the number of range deletions is >= this limit");
|
|
|
|
|
Delay bottommost level single file compactions (#11701)
Summary:
For leveled compaction, RocksDB has a special kind of compaction with reason "kBottommmostFiles" that compacts bottommost level files to clear data held by snapshots (more detail in https://github.com/facebook/rocksdb/issues/3009). Such compactions can happen soon after a relevant snapshot is released. For some use cases, a bottommost file may contain only a small amount of keys that can be cleared, so compacting such a file has a high write amp. In addition, these bottommost files may be compacted in compactions with reason other than "kBottommmostFiles" if we wait for some time (so that enough data is ingested to trigger such a compaction). This PR introduces an option `bottommost_file_compaction_delay` to specify the delay of these bottommost level single file compactions.
* The main change is in `VersionStorageInfo::ComputeBottommostFilesMarkedForCompaction()` where we only add a file to `bottommost_files_marked_for_compaction_` if it oldest_snapshot is larger than its non-zero largest_seqno **and** the file is old enough. Note that if a file is not old enough but its largest_seqno is less than oldest_snapshot, we exclude it from the calculation of `bottommost_files_mark_threshold_`. This makes the change simpler, but such a file's eligibility for compaction will only be checked the next time `ComputeBottommostFilesMarkedForCompaction()` is called. This happens when a new Version is created (compaction, flush, SetOptions()...), a new enough snapshot is released (`VersionStorageInfo::UpdateOldestSnapshot()`) or when a compaction is picked and compaction score has to be re-calculated.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11701
Test Plan:
* Add two unit tests to test when bottommost_file_compaction_delay > 0.
* Ran crash test with the new option.
Reviewed By: jaykorean, ajkr
Differential Revision: D48331564
Pulled By: cbi42
fbshipit-source-id: c584f3dc5f6354fce3ed65f4c6366dc450b15ba8
2023-08-17 00:45:44 +00:00
|
|
|
DEFINE_uint32(bottommost_file_compaction_delay, 0,
|
|
|
|
"Delay kBottommostFiles compaction by this amount of seconds."
|
|
|
|
"See more in option comment.");
|
|
|
|
|
2023-08-24 21:58:27 +00:00
|
|
|
DEFINE_bool(auto_readahead_size, false,
|
|
|
|
"Does auto tuning of readahead_size when enabled during scans.");
|
|
|
|
|
Add missing db crash options (#12414)
Summary:
**Context/Summary:**
We are doing a sweep in all public options, including but not limited to the `Options`, `Read/WriteOptions`, `IngestExternalFileOptions`, cache options.., to find and add the uncovered ones into db crash. The options included in this PR require minimum changes to db crash other than adding the options themselves.
A bonus change: to surface new issues by improved coverage in stderror, we decided to fail/terminate crash test for manual compactions (CompactFiles, CompactRange()) on meaningful errors. See https://github.com/facebook/rocksdb/pull/12414/files#diff-5c4ced6afb6a90e27fec18ab03b2cd89e8f99db87791b4ecc6fa2694284d50c0R2528-R2532, https://github.com/facebook/rocksdb/pull/12414/files#diff-5c4ced6afb6a90e27fec18ab03b2cd89e8f99db87791b4ecc6fa2694284d50c0R2330-R2336 for more.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12414
Test Plan:
- Run `python3 ./tools/db_crashtest.py --simple blackbox` for 10 minutes to ensure no trivial failure
- Run `python3 tools/db_crashtest.py --simple blackbox --compact_files_one_in=1 --compact_range_one_in=1 --read_fault_one_in=1 --write_fault_one_in=1 --interval=50` for a while to ensure the bonus change does not result in trivial crash/termination of stress test
Reviewed By: ajkr, jowlyzhang, cbi42
Differential Revision: D54691774
Pulled By: hx235
fbshipit-source-id: 50443dfb6aaabd8e24c79a2e42b68c6de877be88
2024-03-13 00:24:12 +00:00
|
|
|
DEFINE_bool(allow_fallocate, ROCKSDB_NAMESPACE::Options().allow_fallocate,
|
|
|
|
"Options.allow_fallocate");
|
|
|
|
|
|
|
|
DEFINE_int32(table_cache_numshardbits,
|
|
|
|
ROCKSDB_NAMESPACE::Options().table_cache_numshardbits,
|
|
|
|
"Options.table_cache_numshardbits");
|
|
|
|
|
|
|
|
DEFINE_uint64(log_readahead_size,
|
|
|
|
ROCKSDB_NAMESPACE::Options().log_readahead_size,
|
|
|
|
"Options.log_readahead_size");
|
|
|
|
|
|
|
|
DEFINE_uint64(bgerror_resume_retry_interval,
|
|
|
|
ROCKSDB_NAMESPACE::Options().bgerror_resume_retry_interval,
|
|
|
|
"Options.bgerror_resume_retry_interval");
|
|
|
|
|
|
|
|
DEFINE_uint64(delete_obsolete_files_period_micros,
|
|
|
|
ROCKSDB_NAMESPACE::Options().delete_obsolete_files_period_micros,
|
|
|
|
"Options.delete_obsolete_files_period_micros");
|
|
|
|
|
|
|
|
DEFINE_uint64(max_log_file_size, ROCKSDB_NAMESPACE::Options().max_log_file_size,
|
|
|
|
"Options.max_log_file_sizes");
|
|
|
|
|
|
|
|
DEFINE_uint64(log_file_time_to_roll,
|
|
|
|
ROCKSDB_NAMESPACE::Options().log_file_time_to_roll,
|
|
|
|
"Options.log_file_time_to_roll");
|
|
|
|
|
|
|
|
DEFINE_bool(use_adaptive_mutex, ROCKSDB_NAMESPACE::Options().use_adaptive_mutex,
|
|
|
|
"Options.use_adaptive_mutex");
|
|
|
|
|
|
|
|
DEFINE_bool(advise_random_on_open,
|
|
|
|
ROCKSDB_NAMESPACE::Options().advise_random_on_open,
|
|
|
|
"Options.advise_random_on_open");
|
|
|
|
|
|
|
|
DEFINE_uint64(WAL_ttl_seconds, ROCKSDB_NAMESPACE::Options().WAL_ttl_seconds,
|
|
|
|
"Options.WAL_ttl_seconds");
|
|
|
|
|
|
|
|
DEFINE_uint64(WAL_size_limit_MB, ROCKSDB_NAMESPACE::Options().WAL_size_limit_MB,
|
|
|
|
"Options.WAL_size_limit_MB");
|
|
|
|
|
|
|
|
DEFINE_bool(strict_bytes_per_sync,
|
|
|
|
ROCKSDB_NAMESPACE::Options().strict_bytes_per_sync,
|
|
|
|
"Options.strict_bytes_per_sync");
|
|
|
|
|
|
|
|
DEFINE_bool(avoid_flush_during_shutdown,
|
|
|
|
ROCKSDB_NAMESPACE::Options().avoid_flush_during_shutdown,
|
|
|
|
"Options.avoid_flush_during_shutdown");
|
|
|
|
|
|
|
|
DEFINE_bool(fill_cache, ROCKSDB_NAMESPACE::ReadOptions().fill_cache,
|
|
|
|
"ReadOptions.fill_cache");
|
|
|
|
|
|
|
|
DEFINE_bool(optimize_multiget_for_io,
|
|
|
|
ROCKSDB_NAMESPACE::ReadOptions().optimize_multiget_for_io,
|
|
|
|
"ReadOptions.optimize_multiget_for_io");
|
|
|
|
|
|
|
|
DEFINE_bool(memtable_insert_hint_per_batch,
|
|
|
|
ROCKSDB_NAMESPACE::WriteOptions().memtable_insert_hint_per_batch,
|
|
|
|
"WriteOptions.memtable_insert_hint_per_batch");
|
|
|
|
|
|
|
|
DEFINE_bool(dump_malloc_stats, ROCKSDB_NAMESPACE::Options().dump_malloc_stats,
|
|
|
|
"Options.dump_malloc_stats");
|
|
|
|
|
|
|
|
DEFINE_uint64(stats_history_buffer_size,
|
|
|
|
ROCKSDB_NAMESPACE::Options().stats_history_buffer_size,
|
|
|
|
"Options.stats_history_buffer_size");
|
|
|
|
|
|
|
|
DEFINE_bool(skip_stats_update_on_db_open,
|
|
|
|
ROCKSDB_NAMESPACE::Options().skip_stats_update_on_db_open,
|
|
|
|
"Options.skip_stats_update_on_db_open");
|
|
|
|
|
|
|
|
DEFINE_bool(optimize_filters_for_hits,
|
|
|
|
ROCKSDB_NAMESPACE::Options().optimize_filters_for_hits,
|
|
|
|
"Options.optimize_filters_for_hits");
|
|
|
|
|
|
|
|
DEFINE_uint64(sample_for_compression,
|
|
|
|
ROCKSDB_NAMESPACE::Options().sample_for_compression,
|
|
|
|
"Options.sample_for_compression");
|
|
|
|
|
|
|
|
DEFINE_bool(report_bg_io_stats, ROCKSDB_NAMESPACE::Options().report_bg_io_stats,
|
|
|
|
"Options.report_bg_io_stats");
|
|
|
|
|
|
|
|
DEFINE_bool(
|
|
|
|
cache_index_and_filter_blocks_with_high_priority,
|
|
|
|
ROCKSDB_NAMESPACE::BlockBasedTableOptions()
|
|
|
|
.cache_index_and_filter_blocks_with_high_priority,
|
|
|
|
"BlockBasedTableOptions.cache_index_and_filter_blocks_with_high_priority");
|
|
|
|
|
|
|
|
DEFINE_bool(use_delta_encoding,
|
|
|
|
ROCKSDB_NAMESPACE::BlockBasedTableOptions().use_delta_encoding,
|
|
|
|
"BlockBasedTableOptions.use_delta_encoding");
|
|
|
|
|
|
|
|
DEFINE_bool(verify_compression,
|
|
|
|
ROCKSDB_NAMESPACE::BlockBasedTableOptions().verify_compression,
|
|
|
|
"BlockBasedTableOptions.verify_compression");
|
|
|
|
|
|
|
|
DEFINE_uint32(
|
|
|
|
read_amp_bytes_per_bit,
|
|
|
|
ROCKSDB_NAMESPACE::BlockBasedTableOptions().read_amp_bytes_per_bit,
|
|
|
|
"Options.read_amp_bytes_per_bit");
|
|
|
|
|
|
|
|
DEFINE_bool(
|
|
|
|
enable_index_compression,
|
|
|
|
ROCKSDB_NAMESPACE::BlockBasedTableOptions().enable_index_compression,
|
|
|
|
"BlockBasedTableOptions.enable_index_compression");
|
|
|
|
|
|
|
|
DEFINE_uint32(index_shortening,
|
|
|
|
static_cast<uint32_t>(
|
|
|
|
ROCKSDB_NAMESPACE::BlockBasedTableOptions().index_shortening),
|
|
|
|
"BlockBasedTableOptions.index_shortening");
|
|
|
|
|
|
|
|
DEFINE_uint32(metadata_charge_policy,
|
|
|
|
static_cast<uint32_t>(ROCKSDB_NAMESPACE::ShardedCacheOptions()
|
|
|
|
.metadata_charge_policy),
|
|
|
|
"ShardedCacheOptions.metadata_charge_policy");
|
|
|
|
|
|
|
|
DEFINE_bool(use_adaptive_mutex_lru,
|
|
|
|
ROCKSDB_NAMESPACE::LRUCacheOptions().use_adaptive_mutex,
|
|
|
|
"LRUCacheOptions.use_adaptive_mutex");
|
|
|
|
|
|
|
|
DEFINE_uint32(
|
|
|
|
compress_format_version,
|
|
|
|
static_cast<uint32_t>(ROCKSDB_NAMESPACE::CompressedSecondaryCacheOptions()
|
|
|
|
.compress_format_version),
|
|
|
|
"CompressedSecondaryCacheOptions.compress_format_version");
|
|
|
|
|
|
|
|
DEFINE_uint64(manifest_preallocation_size,
|
|
|
|
ROCKSDB_NAMESPACE::Options().manifest_preallocation_size,
|
|
|
|
"Options.manifest_preallocation_size");
|
|
|
|
|
|
|
|
DEFINE_uint64(max_total_wal_size,
|
|
|
|
ROCKSDB_NAMESPACE::Options().max_total_wal_size,
|
|
|
|
"Options.max_total_wal_size");
|
|
|
|
|
|
|
|
DEFINE_bool(enable_checksum_handoff, false,
|
|
|
|
"If true, include all the supported files in "
|
|
|
|
"Options.checksum_handoff_file. Otherwise include no files.");
|
|
|
|
|
|
|
|
DEFINE_double(high_pri_pool_ratio,
|
|
|
|
ROCKSDB_NAMESPACE::LRUCacheOptions().high_pri_pool_ratio,
|
|
|
|
"LRUCacheOptions.high_pri_pool_ratio");
|
|
|
|
|
|
|
|
DEFINE_double(low_pri_pool_ratio,
|
|
|
|
ROCKSDB_NAMESPACE::LRUCacheOptions().low_pri_pool_ratio,
|
|
|
|
"LRUCacheOptions.low_pri_pool_ratio");
|
|
|
|
|
|
|
|
DEFINE_uint64(soft_pending_compaction_bytes_limit,
|
|
|
|
ROCKSDB_NAMESPACE::Options().soft_pending_compaction_bytes_limit,
|
|
|
|
"Options.soft_pending_compaction_bytes_limit");
|
|
|
|
|
|
|
|
DEFINE_uint64(hard_pending_compaction_bytes_limit,
|
|
|
|
ROCKSDB_NAMESPACE::Options().hard_pending_compaction_bytes_limit,
|
|
|
|
"Options.hard_pending_compaction_bytes_limit");
|
2024-04-08 16:48:03 +00:00
|
|
|
|
|
|
|
DEFINE_bool(enable_sst_partitioner_factory, false,
|
|
|
|
"If true, set Options.sst_partitioner_factory to "
|
|
|
|
"SstPartitionerFixedPrefixFactory with prefix length equal to 1");
|
|
|
|
|
|
|
|
DEFINE_bool(
|
|
|
|
enable_do_not_compress_roles, false,
|
|
|
|
"If true, set CompressedSecondaryCacheOptions.do_not_compress_roles to "
|
|
|
|
"include all cache roles");
|
|
|
|
|
|
|
|
DEFINE_bool(block_align,
|
|
|
|
ROCKSDB_NAMESPACE::BlockBasedTableOptions().block_align,
|
|
|
|
"BlockBasedTableOptions.block_align");
|
|
|
|
|
|
|
|
DEFINE_uint32(
|
|
|
|
lowest_used_cache_tier,
|
|
|
|
static_cast<uint32_t>(ROCKSDB_NAMESPACE::Options().lowest_used_cache_tier),
|
|
|
|
"Options.lowest_used_cache_tier");
|
|
|
|
|
|
|
|
DEFINE_bool(enable_custom_split_merge,
|
|
|
|
ROCKSDB_NAMESPACE::CompressedSecondaryCacheOptions()
|
|
|
|
.enable_custom_split_merge,
|
|
|
|
"CompressedSecondaryCacheOptions.enable_custom_split_merge");
|
|
|
|
|
|
|
|
DEFINE_uint32(
|
|
|
|
adm_policy,
|
|
|
|
static_cast<uint32_t>(ROCKSDB_NAMESPACE::TieredCacheOptions().adm_policy),
|
|
|
|
"TieredCacheOptions.adm_policy");
|
|
|
|
|
2024-04-08 20:45:41 +00:00
|
|
|
DEFINE_string(last_level_temperature, "kUnknown",
|
2024-04-08 16:48:03 +00:00
|
|
|
"Options.last_level_temperature");
|
|
|
|
|
2024-04-08 20:45:41 +00:00
|
|
|
DEFINE_string(default_write_temperature, "kUnknown",
|
2024-04-08 16:48:03 +00:00
|
|
|
"Options.default_write_temperature");
|
|
|
|
|
2024-04-08 20:45:41 +00:00
|
|
|
DEFINE_string(default_temperature, "kUnknown", "Options.default_temperature");
|
2024-04-08 16:48:03 +00:00
|
|
|
|
|
|
|
DEFINE_bool(enable_memtable_insert_with_hint_prefix_extractor,
|
|
|
|
ROCKSDB_NAMESPACE::Options()
|
|
|
|
.memtable_insert_with_hint_prefix_extractor != nullptr,
|
|
|
|
"If true and FLAGS_prefix_size > 0, set "
|
|
|
|
"Options.memtable_insert_with_hint_prefix_extractor to "
|
|
|
|
"be Options.prefix_extractor");
|
2024-04-15 23:11:58 +00:00
|
|
|
|
|
|
|
DEFINE_bool(check_multiget_consistency, true,
|
|
|
|
"If true, check consistency of MultiGet result by comparing it "
|
|
|
|
"with Get's under a snapshot");
|
|
|
|
|
|
|
|
DEFINE_bool(check_multiget_entity_consistency, true,
|
|
|
|
"If true, check consistency of MultiGetEntity result by comparing "
|
|
|
|
"it GetEntity's under a snapshot");
|
|
|
|
|
|
|
|
DEFINE_bool(inplace_update_support,
|
|
|
|
ROCKSDB_NAMESPACE::Options().inplace_update_support,
|
|
|
|
"Options.inplace_update_support");
|
Support pro-actively erasing obsolete block cache entries (#12694)
Summary:
Currently, when files become obsolete, the block cache entries associated with them just age out naturally. With pure LRU, this is not too bad, as once you "use" enough cache entries to (re-)fill the cache, you are guranteed to have purged the obsolete entries. However, HyperClockCache is a counting clock cache with a somewhat longer memory, so could be more negatively impacted by previously-hot cache entries becoming obsolete, and taking longer to age out than newer single-hit entries.
Part of the reason we still have this natural aging-out is that there's almost no connection between block cache entries and the file they are associated with. Everything is hashed into the same pool(s) of entries with nothing like a secondary index based on file. Keeping track of such an index could be expensive.
This change adds a new, mutable CF option `uncache_aggressiveness` for erasing obsolete block cache entries. The process can be speculative, lossy, or unproductive because not all potential block cache entries associated with files will be resident in memory, and attempting to remove them all could be wasted CPU time. Rather than a simple on/off switch, `uncache_aggressiveness` basically tells RocksDB how much CPU you're willing to burn trying to purge obsolete block cache entries. When such efforts are not sufficiently productive for a file, we stop and move on.
The option is in ColumnFamilyOptions so that it is dynamically changeable for already-open files, and customizeable by CF.
Note that this block cache removal happens as part of the process of purging obsolete files, which is often in a background thread (depending on `background_purge_on_iterator_cleanup` and `avoid_unnecessary_blocking_io` options) rather than along CPU critical paths.
Notable auxiliary code details:
* Possibly fixing some issues with trivial moves with `only_delete_metadata`: unnecessary TableCache::Evict in that case and missing from the ObsoleteFileInfo move operator. (Not able to reproduce an current failure.)
* Remove suspicious TableCache::Erase() from VersionSet::AddObsoleteBlobFile() (TODO follow-up item)
Marked EXPERIMENTAL until more thorough validation is complete.
Direct stats of this functionality are omitted because they could be misleading. Block cache hit rate is a better indicator of benefit, and CPU profiling a better indicator of cost.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12694
Test Plan:
* Unit tests added, including refactoring an existing test to make better use of parameterized tests.
* Added to crash test.
* Performance, sample command:
```
for I in `seq 1 10`; do for UA in 300; do for CT in lru_cache fixed_hyper_clock_cache auto_hyper_clock_cache; do rm -rf /dev/shm/test3; TEST_TMPDIR=/dev/shm/test3 /usr/bin/time ./db_bench -benchmarks=readwhilewriting -num=13000000 -read_random_exp_range=6 -write_buffer_size=10000000 -bloom_bits=10 -cache_type=$CT -cache_size=390000000 -cache_index_and_filter_blocks=1 -disable_wal=1 -duration=60 -statistics -uncache_aggressiveness=$UA 2>&1 | grep -E 'micros/op|rocksdb.block.cache.data.(hit|miss)|rocksdb.number.keys.(read|written)|maxresident' | awk '/rocksdb.block.cache.data.miss/ { miss = $4 } /rocksdb.block.cache.data.hit/ { hit = $4 } { print } END { print "hit rate = " ((hit * 1.0) / (miss + hit)) }' | tee -a results-$CT-$UA; done; done; done
```
Averaging 10 runs each case, block cache data block hit rates
```
lru_cache
UA=0 -> hit rate = 0.327, ops/s = 87668, user CPU sec = 139.0
UA=300 -> hit rate = 0.336, ops/s = 87960, user CPU sec = 139.0
fixed_hyper_clock_cache
UA=0 -> hit rate = 0.336, ops/s = 100069, user CPU sec = 139.9
UA=300 -> hit rate = 0.343, ops/s = 100104, user CPU sec = 140.2
auto_hyper_clock_cache
UA=0 -> hit rate = 0.336, ops/s = 97580, user CPU sec = 140.5
UA=300 -> hit rate = 0.345, ops/s = 97972, user CPU sec = 139.8
```
Conclusion: up to roughly 1 percentage point of improved block cache hit rate, likely leading to overall improved efficiency (because the foreground CPU cost of cache misses likely outweighs the background CPU cost of erasure, let alone I/O savings).
Reviewed By: ajkr
Differential Revision: D57932442
Pulled By: pdillinger
fbshipit-source-id: 84a243ca5f965f731f346a4853009780a904af6c
2024-06-07 15:57:11 +00:00
|
|
|
|
|
|
|
DEFINE_uint32(uncache_aggressiveness,
|
|
|
|
ROCKSDB_NAMESPACE::ColumnFamilyOptions().uncache_aggressiveness,
|
|
|
|
"Aggressiveness of erasing cache entries that are likely "
|
|
|
|
"obsolete. 0 = disabled, 1 = minimum, 100 = moderate, 10000 = "
|
|
|
|
"normal max");
|
|
|
|
|
2024-08-19 20:53:25 +00:00
|
|
|
DEFINE_bool(paranoid_memory_checks,
|
|
|
|
ROCKSDB_NAMESPACE::Options().paranoid_memory_checks,
|
|
|
|
"Sets CF option paranoid_memory_checks.");
|
|
|
|
|
2019-12-09 07:49:32 +00:00
|
|
|
#endif // GFLAGS
|