forked from continuwuation/rocksdb
37176a4a44
Summary:
Adds auto-tuning of manifest file size to avoid the need to scale `max_manifest_file_size` in proportion to things like number of SST files to properly balance (a) manifest file write amp and new file creation, vs. (b) manifest file space amp and replay time, including non-incremental space usage in backups. (Manifest file write amp comes from re-writing a "live" record when the manifest file is re-created, or "compacted"; space amp is usage beyond what would be used by a compacted manifest file.) In more detail,
* Add new option `max_manifest_space_amp_pct` with default value of 500, which defaults to 0.2 write amp and up to roughly 5.0 space amp, except `max_manifest_file_size` is treated as the "minimum" size before re-creating ("compacting") the manifest file.
* `max_manifest_file_size` in a way means the same thing, with the same default of 1GB, but in a way has taken on a new role. What is the same is that we do not re-create the manifest file before reaching this size (except for DB re-open), and so users are very unlikely to see a change in default behavior (auto-tuning only kicking in if auto-tuning would exceed 1GB for effective max size for the current manifest file). The new role is as a file size lower bound before auto-tuning kicks in, to minimize churn in files considered "negligibly small." We recommend a new setting of around 1MB or even smaller like 64KB, and expect something like this to become the default soon.
* These two options along with `manifest_preallocation_size` are now mutable with SetDBOptions. The effect is nearly immediate, affecting the next write to the current manifest file.
Also in this PR:
* Refactoring of VersionSet to allow it to get (more) settings from MutableDBOptions. This touches a number of files in not very interesting ways, but notably we have to be careful about thread-safe access to MutableDBOptions fields, and even fields within VersionSet. I have decided to save copies of relevant fields from MutableDBOptions to simplify testing, etc. by not saving a reference to MutableDBOptions but getting notified of updates.
* Updated some logging in VersionSet to provide some basic data about final and compacted manifest sizes (effects of auto-tuning), making sure to avoid I/O while holding DB mutex.
* Added db_etc3_test.cc which is intended as a successor to db_test and db_test2, but having "test.cc" in its name for easier exclusion of test files when using `git grep`. Intended follow-up: rename db_test2 to db_etc2_test
* Moved+updated `ManifestRollOver` test to the new file to be closer to other manifest file rollover testing.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/14076
Test Plan:
As for correctness, new unit test AutoTuneManifestSize is pretty thorough. Some other unit tests updated appropriately. Manual tests in the performance section were also audited for expected behavior based on the new logging in the DB LOG. Example LOG data with -max_manifest_file_size=2048 -max_manifest_space_amp_pct=500:
```
2025/10/24-11:12:48.979472 2150678 [/version_set.cc:5927] Created manifest 5, compacted+appended from 52 to 116
2025/10/24-11:12:49.626441 2150682 [/version_set.cc:5927] Created manifest 24, compacted+appended from 2169 to 1801
2025/10/24-11:12:52.194592 2150682 [/version_set.cc:5927] Created manifest 91, compacted+appended from 10913 to 8707
2025/10/24-11:13:02.969944 2150682 [/version_set.cc:5927] Created manifest 362, compacted+appended from 52259 to 13321
2025/10/24-11:13:18.815120 2150681 [/version_set.cc:5927] Created manifest 765, compacted+appended from 80064 to 13304
2025/10/24-11:13:35.590905 2150681 [/version_set.cc:5927] Created manifest 1167, compacted+appended from 79863 to 13304
```
As you can see, it only took a few iterations of ramp-up to settle on the auto-tuned max manifest size for tracking ~122 live SST files, around 80KB and compacting down to about 13KB. (13KB * (500 + 100) / 100 = 78KB). With the default large setting for max_manifest_file_size, we end up with a 232KB manifest, which is more than 90% wasted space. (A long-running DB would be much worse.)
As for performance, we don't expect a difference, even with TransactionDB because actual writing of the manifest is done without holding the DB mutex. I was not able to see a performance regression using db_bench with FIFO compaction and >1000 ~10MB SST files, including settings of -max_manifest_file_size=2048 -max_manifest_space_amp_pct={500,10,0}. No "hiccups" visible with -histogram either.
I also tried seeding a 1 second delay in writing new manifest files (other than the first). This had no significant effect at -max_manifest_space_amp_pct=500 but at 100 started causing write stalls in my test. In many ways this is kind of a worst case scenario and out-of-proportion test, but gives me more confidence that a higher number like 500 is probably the best balance in general.
Reviewed By: xingbowang
Differential Revision: D85445178
Pulled By: pdillinger
fbshipit-source-id: 1e6e07e89c586762dd65c65bb7cb2b8b719513f9
77 lines
3.1 KiB
C++
77 lines
3.1 KiB
C++
// Copyright (c) Meta Platforms, Inc. and affiliates.
|
|
// 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).
|
|
|
|
#pragma once
|
|
|
|
#include "db/version_set.h"
|
|
|
|
namespace ROCKSDB_NAMESPACE {
|
|
|
|
// Instead of opening a `DB` to perform certain manifest updates, this
|
|
// uses the underlying `VersionSet` API to read and modify the MANIFEST. This
|
|
// allows us to use the user's real options, while not having to worry about
|
|
// the DB persisting new SST files via flush/compaction or attempting to read/
|
|
// compact files which may fail, particularly for the file we intend to remove
|
|
// (the user may want to remove an already deleted file from MANIFEST).
|
|
class OfflineManifestWriter {
|
|
public:
|
|
OfflineManifestWriter(const DBOptions& options, const std::string& db_path)
|
|
: wc_(options.delayed_write_rate),
|
|
wb_(options.db_write_buffer_size),
|
|
immutable_db_options_(WithDbPath(options, db_path)),
|
|
tc_(NewLRUCache(1 << 20 /* capacity */,
|
|
options.table_cache_numshardbits)),
|
|
versions_(db_path, &immutable_db_options_, MutableDBOptions{options},
|
|
sopt_, tc_.get(), &wb_, &wc_,
|
|
/*block_cache_tracer=*/nullptr, /*io_tracer=*/nullptr,
|
|
/*db_id=*/"", /*db_session_id=*/"",
|
|
options.daily_offpeak_time_utc,
|
|
/*error_handler=*/nullptr,
|
|
/*read_only=*/false) {}
|
|
|
|
Status Recover(const std::vector<ColumnFamilyDescriptor>& column_families) {
|
|
return versions_.Recover(column_families, /*read_only*/ false,
|
|
/*db_id*/ nullptr,
|
|
/*no_error_if_files_missing*/ true);
|
|
}
|
|
|
|
Status LogAndApply(const ReadOptions& read_options,
|
|
const WriteOptions& write_options, ColumnFamilyData* cfd,
|
|
VersionEdit* edit,
|
|
FSDirectory* dir_contains_current_file) {
|
|
// Use `mutex` to imitate a locked DB mutex when calling `LogAndApply()`.
|
|
InstrumentedMutex mutex;
|
|
mutex.Lock();
|
|
Status s = versions_.LogAndApply(cfd, read_options, write_options, edit,
|
|
&mutex, dir_contains_current_file,
|
|
false /* new_descriptor_log */);
|
|
mutex.Unlock();
|
|
return s;
|
|
}
|
|
|
|
VersionSet& Versions() { return versions_; }
|
|
const ImmutableDBOptions& IOptions() { return immutable_db_options_; }
|
|
|
|
private:
|
|
WriteController wc_;
|
|
WriteBufferManager wb_;
|
|
ImmutableDBOptions immutable_db_options_;
|
|
std::shared_ptr<Cache> tc_;
|
|
EnvOptions sopt_;
|
|
VersionSet versions_;
|
|
|
|
static ImmutableDBOptions WithDbPath(const DBOptions& options,
|
|
const std::string& db_path) {
|
|
ImmutableDBOptions rv(options);
|
|
if (rv.db_paths.empty()) {
|
|
// `VersionSet` expects options that have been through
|
|
// `SanitizeOptions()`, which would sanitize an empty `db_paths`.
|
|
rv.db_paths.emplace_back(db_path, 0 /* target_size */);
|
|
}
|
|
return rv;
|
|
}
|
|
};
|
|
|
|
} // namespace ROCKSDB_NAMESPACE
|