From bdf2fd0a78b278ad5ebb14c23d59207139ed1d2e Mon Sep 17 00:00:00 2001 From: Garvit Juniwal Date: Sun, 6 May 2018 16:26:32 -0700 Subject: [PATCH] rocksdb: use max_manifest_file_size option Cockroach uses a single long running rocksdb instance for the entire process lifetime, which could be many months. By default, rocksdb tracks filesystem state changes in a log file called the MANIFEST, which grows without bound until the instance is re-opened. We should bound the maximum file size of rocksdb MANIFEST using the corresponding rocksdb option to prevent unbounded growth. The MANIFEST file grew to several GBs in size in a customer bug report but that was probably because of some other bad behavior in rocksdb state management. We do want to bound the MANIFEST size in such cases as well. Release note: None --- c-deps/libroach/options.cc | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/c-deps/libroach/options.cc b/c-deps/libroach/options.cc index 46994e15b486..50bf187988d7 100644 --- a/c-deps/libroach/options.cc +++ b/c-deps/libroach/options.cc @@ -262,6 +262,12 @@ rocksdb::Options DBMakeOptions(DBOptions db_opts) { options.target_file_size_base = 4 << 20; // 4 MB options.target_file_size_multiplier = 2; + // Because we open a long running rocksdb instance, we do not want the + // manifest file to grow unbounded. Assuming each manifest entry is about 1 + // KB, this allows for 128 K entries. This could account for several hours to + // few months of runtime without rolling based on the workload. + options.max_manifest_file_size = 128 << 20; // 128 MB + rocksdb::BlockBasedTableOptions table_options; if (db_opts.cache != nullptr) { table_options.block_cache = db_opts.cache->rep;