Cap concurrent arena's shard block size to 128KB (#4147)
Summary: Users sometime see their memtable size far smaller than expected. They probably have hit a fragementation of shard blocks. Cap their size anyway to reduce the impact of problem. 128KB is conservative so I don't imagine it can cause any performance problem. Pull Request resolved: https://github.com/facebook/rocksdb/pull/4147 Differential Revision: D8886706 Pulled By: siying fbshipit-source-id: 8528a2a4196aa4457274522e2565fd3ff28f621e
This commit is contained in:
parent
79f009f22e
commit
4bb1e239b5
@ -18,9 +18,17 @@ namespace rocksdb {
|
||||
__thread size_t ConcurrentArena::tls_cpuid = 0;
|
||||
#endif
|
||||
|
||||
namespace {
|
||||
// If the shard block size is too large, in the worst case, every core
|
||||
// allocates a block without populate it. If the shared block size is
|
||||
// 1MB, 64 cores will quickly allocate 64MB, and may quickly trigger a
|
||||
// flush. Cap the size instead.
|
||||
const size_t kMaxShardBlockSize = size_t{128 * 1024};
|
||||
} // namespace
|
||||
|
||||
ConcurrentArena::ConcurrentArena(size_t block_size, AllocTracker* tracker,
|
||||
size_t huge_page_size)
|
||||
: shard_block_size_(block_size / 8),
|
||||
: shard_block_size_(std::min(kMaxShardBlockSize, block_size / 8)),
|
||||
shards_(),
|
||||
arena_(block_size, tracker, huge_page_size) {
|
||||
Fixup();
|
||||
|
Loading…
Reference in New Issue
Block a user