0050a73a4f
Summary: This change standardizes on a new 16-byte cache key format for block cache (incl compressed and secondary) and persistent cache (but not table cache and row cache). The goal is a really fast cache key with practically ideal stability and uniqueness properties without external dependencies (e.g. from FileSystem). A fixed key size of 16 bytes should enable future optimizations to the concurrent hash table for block cache, which is a heavy CPU user / bottleneck, but there appears to be measurable performance improvement even with no changes to LRUCache. This change replaces a lot of disjointed and ugly code handling cache keys with calls to a simple, clean new internal API (cache_key.h). (Preserving the old cache key logic under an option would be very ugly and likely negate the performance gain of the new approach. Complete replacement carries some inherent risk, but I think that's acceptable with sufficient analysis and testing.) The scheme for encoding new cache keys is complicated but explained in cache_key.cc. Also: EndianSwapValue is moved to math.h to be next to other bit operations. (Explains some new include "math.h".) ReverseBits operation added and unit tests added to hash_test for both. Fixes https://github.com/facebook/rocksdb/issues/7405 (presuming a root cause) Pull Request resolved: https://github.com/facebook/rocksdb/pull/9126 Test Plan: ### Basic correctness Several tests needed updates to work with the new functionality, mostly because we are no longer relying on filesystem for stable cache keys so table builders & readers need more context info to agree on cache keys. This functionality is so core, a huge number of existing tests exercise the cache key functionality. ### Performance Create db with `TEST_TMPDIR=/dev/shm ./db_bench -bloom_bits=10 -benchmarks=fillrandom -num=3000000 -partition_index_and_filters` And test performance with `TEST_TMPDIR=/dev/shm ./db_bench -readonly -use_existing_db -bloom_bits=10 -benchmarks=readrandom -num=3000000 -duration=30 -cache_index_and_filter_blocks -cache_size=250000 -threads=4` using DEBUG_LEVEL=0 and simultaneous before & after runs. Before ops/sec, avg over 100 runs: 121924 After ops/sec, avg over 100 runs: 125385 (+2.8%) ### Collision probability I have built a tool, ./cache_bench -stress_cache_key to broadly simulate host-wide cache activity over many months, by making some pessimistic simplifying assumptions: * Every generated file has a cache entry for every byte offset in the file (contiguous range of cache keys) * All of every file is cached for its entire lifetime We use a simple table with skewed address assignment and replacement on address collision to simulate files coming & going, with quite a variance (super-Poisson) in ages. Some output with `./cache_bench -stress_cache_key -sck_keep_bits=40`: ``` Total cache or DBs size: 32TiB Writing 925.926 MiB/s or 76.2939TiB/day Multiply by 9.22337e+18 to correct for simulation losses (but still assume whole file cached) ``` These come from default settings of 2.5M files per day of 32 MB each, and `-sck_keep_bits=40` means that to represent a single file, we are only keeping 40 bits of the 128-bit cache key. With file size of 2\*\*25 contiguous keys (pessimistic), our simulation is about 2\*\*(128-40-25) or about 9 billion billion times more prone to collision than reality. More default assumptions, relatively pessimistic: * 100 DBs in same process (doesn't matter much) * Re-open DB in same process (new session ID related to old session ID) on average every 100 files generated * Restart process (all new session IDs unrelated to old) 24 times per day After enough data, we get a result at the end: ``` (keep 40 bits) 17 collisions after 2 x 90 days, est 10.5882 days between (9.76592e+19 corrected) ``` If we believe the (pessimistic) simulation and the mathematical generalization, we would need to run a billion machines all for 97 billion days to expect a cache key collision. To help verify that our generalization ("corrected") is robust, we can make our simulation more precise with `-sck_keep_bits=41` and `42`, which takes more running time to get enough data: ``` (keep 41 bits) 16 collisions after 4 x 90 days, est 22.5 days between (1.03763e+20 corrected) (keep 42 bits) 19 collisions after 10 x 90 days, est 47.3684 days between (1.09224e+20 corrected) ``` The generalized prediction still holds. With the `-sck_randomize` option, we can see that we are beating "random" cache keys (except offsets still non-randomized) by a modest amount (roughly 20x less collision prone than random), which should make us reasonably comfortable even in "degenerate" cases: ``` 197 collisions after 1 x 90 days, est 0.456853 days between (4.21372e+18 corrected) ``` I've run other tests to validate other conditions behave as expected, never behaving "worse than random" unless we start chopping off structured data. Reviewed By: zhichao-cao Differential Revision: D33171746 Pulled By: pdillinger fbshipit-source-id: f16a57e369ed37be5e7e33525ace848d0537c88f
192 lines
8.0 KiB
C++
192 lines
8.0 KiB
C++
// 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.
|
|
|
|
#pragma once
|
|
|
|
#include <atomic>
|
|
#include <cstddef>
|
|
#include <cstdint>
|
|
#include <memory>
|
|
#include <vector>
|
|
|
|
#include "cache/cache_entry_roles.h"
|
|
#include "rocksdb/cache.h"
|
|
#include "rocksdb/slice.h"
|
|
#include "rocksdb/status.h"
|
|
#include "table/block_based/block_based_table_reader.h"
|
|
#include "util/coding.h"
|
|
|
|
namespace ROCKSDB_NAMESPACE {
|
|
|
|
template <CacheEntryRole R>
|
|
class CacheReservationHandle;
|
|
|
|
// CacheReservationManager is for reserving cache space for the memory used
|
|
// through inserting/releasing dummy entries in the cache.
|
|
//
|
|
// This class is NOT thread-safe, except that GetTotalReservedCacheSize()
|
|
// can be called without external synchronization.
|
|
class CacheReservationManager
|
|
: public std::enable_shared_from_this<CacheReservationManager> {
|
|
public:
|
|
// Construct a CacheReservationManager
|
|
// @param cache The cache where dummy entries are inserted and released for
|
|
// reserving cache space
|
|
// @param delayed_decrease If set true, then dummy entries won't be released
|
|
// immediately when memory usage decreases.
|
|
// Instead, it will be released when the memory usage
|
|
// decreases to 3/4 of what we have reserved so far.
|
|
// This is for saving some future dummy entry
|
|
// insertion when memory usage increases are likely to
|
|
// happen in the near future.
|
|
explicit CacheReservationManager(std::shared_ptr<Cache> cache,
|
|
bool delayed_decrease = false);
|
|
|
|
// no copy constructor, copy assignment, move constructor, move assignment
|
|
CacheReservationManager(const CacheReservationManager &) = delete;
|
|
CacheReservationManager &operator=(const CacheReservationManager &) = delete;
|
|
CacheReservationManager(CacheReservationManager &&) = delete;
|
|
CacheReservationManager &operator=(CacheReservationManager &&) = delete;
|
|
|
|
~CacheReservationManager();
|
|
|
|
template <CacheEntryRole R>
|
|
|
|
// One of the two ways of reserving/releasing cache,
|
|
// see CacheReservationManager::MakeCacheReservation() for the other.
|
|
// Use ONLY one of them to prevent unexpected behavior.
|
|
//
|
|
// Insert and release dummy entries in the cache to
|
|
// match the size of total dummy entries with the least multiple of
|
|
// kSizeDummyEntry greater than or equal to new_mem_used
|
|
//
|
|
// Insert dummy entries if new_memory_used > cache_allocated_size_;
|
|
//
|
|
// Release dummy entries if new_memory_used < cache_allocated_size_
|
|
// (and new_memory_used < cache_allocated_size_ * 3/4
|
|
// when delayed_decrease is set true);
|
|
//
|
|
// Keey dummy entries the same if (1) new_memory_used == cache_allocated_size_
|
|
// or (2) new_memory_used is in the interval of
|
|
// [cache_allocated_size_ * 3/4, cache_allocated_size) when delayed_decrease
|
|
// is set true.
|
|
//
|
|
// @param new_memory_used The number of bytes used by new memory
|
|
// The most recent new_memoy_used passed in will be returned
|
|
// in GetTotalMemoryUsed() even when the call return non-ok status.
|
|
//
|
|
// Since the class is NOT thread-safe, external synchronization on the
|
|
// order of calling UpdateCacheReservation() is needed if you want
|
|
// GetTotalMemoryUsed() indeed returns the latest memory used.
|
|
//
|
|
// @return On inserting dummy entries, it returns Status::OK() if all dummy
|
|
// entry insertions succeed.
|
|
// Otherwise, it returns the first non-ok status;
|
|
// On releasing dummy entries, it always returns Status::OK().
|
|
// On keeping dummy entries the same, it always returns Status::OK().
|
|
Status UpdateCacheReservation(std::size_t new_memory_used);
|
|
|
|
// One of the two ways of reserving/releasing cache,
|
|
// see CacheReservationManager::UpdateCacheReservation() for the other.
|
|
// Use ONLY one of them to prevent unexpected behavior.
|
|
//
|
|
// Insert dummy entries in the cache for the incremental memory usage
|
|
// to match the size of total dummy entries with the least multiple of
|
|
// kSizeDummyEntry greater than or equal to the total memory used.
|
|
//
|
|
// A CacheReservationHandle is returned as an output parameter.
|
|
// The reserved dummy entries are automatically released on the destruction of
|
|
// this handle, which achieves better RAII per cache reservation.
|
|
//
|
|
// WARNING: Deallocate all the handles of the CacheReservationManager object
|
|
// before deallocating the object to prevent unexpected behavior.
|
|
//
|
|
// @param incremental_memory_used The number of bytes increased in memory
|
|
// usage.
|
|
//
|
|
// Calling GetTotalMemoryUsed() afterward will return the total memory
|
|
// increased by this number, even when calling MakeCacheReservation()
|
|
// returns non-ok status.
|
|
//
|
|
// Since the class is NOT thread-safe, external synchronization in
|
|
// calling MakeCacheReservation() is needed if you want
|
|
// GetTotalMemoryUsed() indeed returns the latest memory used.
|
|
//
|
|
// @param handle An pointer to std::unique_ptr<CacheReservationHandle<R>> that
|
|
// manages the lifetime of the handle and its cache reservation.
|
|
//
|
|
// @return It returns Status::OK() if all dummy
|
|
// entry insertions succeed.
|
|
// Otherwise, it returns the first non-ok status;
|
|
//
|
|
// REQUIRES: handle != nullptr
|
|
// REQUIRES: The CacheReservationManager object is NOT managed by
|
|
// std::unique_ptr as CacheReservationHandle needs to
|
|
// shares ownership to the CacheReservationManager object.
|
|
template <CacheEntryRole R>
|
|
Status MakeCacheReservation(
|
|
std::size_t incremental_memory_used,
|
|
std::unique_ptr<CacheReservationHandle<R>> *handle);
|
|
|
|
// Return the size of the cache (which is a multiple of kSizeDummyEntry)
|
|
// successfully reserved by calling UpdateCacheReservation().
|
|
//
|
|
// When UpdateCacheReservation() returns non-ok status,
|
|
// calling GetTotalReservedCacheSize() after that might return a slightly
|
|
// smaller number than the actual reserved cache size due to
|
|
// the returned number will always be a multiple of kSizeDummyEntry
|
|
// and cache full might happen in the middle of inserting a dummy entry.
|
|
std::size_t GetTotalReservedCacheSize();
|
|
|
|
// Return the latest total memory used indicated by the most recent call of
|
|
// UpdateCacheReservation(std::size_t new_memory_used);
|
|
std::size_t GetTotalMemoryUsed();
|
|
|
|
static constexpr std::size_t GetDummyEntrySize() { return kSizeDummyEntry; }
|
|
|
|
// For testing only - it is to help ensure the NoopDeleterForRole<R>
|
|
// accessed from CacheReservationManager and the one accessed from the test
|
|
// are from the same translation units
|
|
template <CacheEntryRole R>
|
|
static Cache::DeleterFn TEST_GetNoopDeleterForRole();
|
|
|
|
private:
|
|
static constexpr std::size_t kSizeDummyEntry = 256 * 1024;
|
|
|
|
Slice GetNextCacheKey();
|
|
template <CacheEntryRole R>
|
|
Status IncreaseCacheReservation(std::size_t new_mem_used);
|
|
Status DecreaseCacheReservation(std::size_t new_mem_used);
|
|
|
|
std::shared_ptr<Cache> cache_;
|
|
bool delayed_decrease_;
|
|
std::atomic<std::size_t> cache_allocated_size_;
|
|
std::size_t memory_used_;
|
|
std::vector<Cache::Handle *> dummy_handles_;
|
|
CacheKey cache_key_;
|
|
};
|
|
|
|
// CacheReservationHandle is for managing the lifetime of a cache reservation
|
|
// This class is NOT thread-safe
|
|
template <CacheEntryRole R>
|
|
class CacheReservationHandle {
|
|
public:
|
|
// REQUIRES: cache_res_mgr != nullptr
|
|
explicit CacheReservationHandle(
|
|
std::size_t incremental_memory_used,
|
|
std::shared_ptr<CacheReservationManager> cache_res_mgr);
|
|
|
|
~CacheReservationHandle();
|
|
|
|
private:
|
|
std::size_t incremental_memory_used_;
|
|
std::shared_ptr<CacheReservationManager> cache_res_mgr_;
|
|
};
|
|
} // namespace ROCKSDB_NAMESPACE
|