|
|
|
// 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
|
support for concurrent adds to memtable
Summary:
This diff adds support for concurrent adds to the skiplist memtable
implementations. Memory allocation is made thread-safe by the addition of
a spinlock, with small per-core buffers to avoid contention. Concurrent
memtable writes are made via an additional method and don't impose a
performance overhead on the non-concurrent case, so parallelism can be
selected on a per-batch basis.
Write thread synchronization is an increasing bottleneck for higher levels
of concurrency, so this diff adds --enable_write_thread_adaptive_yield
(default off). This feature causes threads joining a write batch
group to spin for a short time (default 100 usec) using sched_yield,
rather than going to sleep on a mutex. If the timing of the yield calls
indicates that another thread has actually run during the yield then
spinning is avoided. This option improves performance for concurrent
situations even without parallel adds, although it has the potential to
increase CPU usage (and the heuristic adaptation is not yet mature).
Parallel writes are not currently compatible with
inplace updates, update callbacks, or delete filtering.
Enable it with --allow_concurrent_memtable_write (and
--enable_write_thread_adaptive_yield). Parallel memtable writes
are performance neutral when there is no actual parallelism, and in
my experiments (SSD server-class Linux and varying contention and key
sizes for fillrandom) they are always a performance win when there is
more than one thread.
Statistics are updated earlier in the write path, dropping the number
of DB mutex acquisitions from 2 to 1 for almost all cases.
This diff was motivated and inspired by Yahoo's cLSM work. It is more
conservative than cLSM: RocksDB's write batch group leader role is
preserved (along with all of the existing flush and write throttling
logic) and concurrent writers are blocked until all memtable insertions
have completed and the sequence number has been advanced, to preserve
linearizability.
My test config is "db_bench -benchmarks=fillrandom -threads=$T
-batch_size=1 -memtablerep=skip_list -value_size=100 --num=1000000/$T
-level0_slowdown_writes_trigger=9999 -level0_stop_writes_trigger=9999
-disable_auto_compactions --max_write_buffer_number=8
-max_background_flushes=8 --disable_wal --write_buffer_size=160000000
--block_size=16384 --allow_concurrent_memtable_write" on a two-socket
Xeon E5-2660 @ 2.2Ghz with lots of memory and an SSD hard drive. With 1
thread I get ~440Kops/sec. Peak performance for 1 socket (numactl
-N1) is slightly more than 1Mops/sec, at 16 threads. Peak performance
across both sockets happens at 30 threads, and is ~900Kops/sec, although
with fewer threads there is less performance loss when the system has
background work.
Test Plan:
1. concurrent stress tests for InlineSkipList and DynamicBloom
2. make clean; make check
3. make clean; DISABLE_JEMALLOC=1 make valgrind_check; valgrind db_bench
4. make clean; COMPILE_WITH_TSAN=1 make all check; db_bench
5. make clean; COMPILE_WITH_ASAN=1 make all check; db_bench
6. make clean; OPT=-DROCKSDB_LITE make check
7. verify no perf regressions when disabled
Reviewers: igor, sdong
Reviewed By: sdong
Subscribers: MarkCallaghan, IslamAbdelRahman, anthony, yhchiang, rven, sdong, guyg8, kradhakrishnan, dhruba
Differential Revision: https://reviews.facebook.net/D50589
9 years ago
|
|
|
#include <assert.h>
|
|
|
|
|
support for concurrent adds to memtable
Summary:
This diff adds support for concurrent adds to the skiplist memtable
implementations. Memory allocation is made thread-safe by the addition of
a spinlock, with small per-core buffers to avoid contention. Concurrent
memtable writes are made via an additional method and don't impose a
performance overhead on the non-concurrent case, so parallelism can be
selected on a per-batch basis.
Write thread synchronization is an increasing bottleneck for higher levels
of concurrency, so this diff adds --enable_write_thread_adaptive_yield
(default off). This feature causes threads joining a write batch
group to spin for a short time (default 100 usec) using sched_yield,
rather than going to sleep on a mutex. If the timing of the yield calls
indicates that another thread has actually run during the yield then
spinning is avoided. This option improves performance for concurrent
situations even without parallel adds, although it has the potential to
increase CPU usage (and the heuristic adaptation is not yet mature).
Parallel writes are not currently compatible with
inplace updates, update callbacks, or delete filtering.
Enable it with --allow_concurrent_memtable_write (and
--enable_write_thread_adaptive_yield). Parallel memtable writes
are performance neutral when there is no actual parallelism, and in
my experiments (SSD server-class Linux and varying contention and key
sizes for fillrandom) they are always a performance win when there is
more than one thread.
Statistics are updated earlier in the write path, dropping the number
of DB mutex acquisitions from 2 to 1 for almost all cases.
This diff was motivated and inspired by Yahoo's cLSM work. It is more
conservative than cLSM: RocksDB's write batch group leader role is
preserved (along with all of the existing flush and write throttling
logic) and concurrent writers are blocked until all memtable insertions
have completed and the sequence number has been advanced, to preserve
linearizability.
My test config is "db_bench -benchmarks=fillrandom -threads=$T
-batch_size=1 -memtablerep=skip_list -value_size=100 --num=1000000/$T
-level0_slowdown_writes_trigger=9999 -level0_stop_writes_trigger=9999
-disable_auto_compactions --max_write_buffer_number=8
-max_background_flushes=8 --disable_wal --write_buffer_size=160000000
--block_size=16384 --allow_concurrent_memtable_write" on a two-socket
Xeon E5-2660 @ 2.2Ghz with lots of memory and an SSD hard drive. With 1
thread I get ~440Kops/sec. Peak performance for 1 socket (numactl
-N1) is slightly more than 1Mops/sec, at 16 threads. Peak performance
across both sockets happens at 30 threads, and is ~900Kops/sec, although
with fewer threads there is less performance loss when the system has
background work.
Test Plan:
1. concurrent stress tests for InlineSkipList and DynamicBloom
2. make clean; make check
3. make clean; DISABLE_JEMALLOC=1 make valgrind_check; valgrind db_bench
4. make clean; COMPILE_WITH_TSAN=1 make all check; db_bench
5. make clean; COMPILE_WITH_ASAN=1 make all check; db_bench
6. make clean; OPT=-DROCKSDB_LITE make check
7. verify no perf regressions when disabled
Reviewers: igor, sdong
Reviewed By: sdong
Subscribers: MarkCallaghan, IslamAbdelRahman, anthony, yhchiang, rven, sdong, guyg8, kradhakrishnan, dhruba
Differential Revision: https://reviews.facebook.net/D50589
9 years ago
|
|
|
#include <atomic>
|
remove dependency on options.h for port_posix.h andport_win.h (#11214)
Summary:
The files in `port/`, such as `port_posix.h`, are layering over the system libraries, so shouldn't include the DB-specific files like `options.h`. This PR remove this dependency.
# How
The reason that `port_posix.h` (or `port_win.h`) include `options.h` is to use `CpuPriority`, as there is a method `SetCpuPriority()` in `port_posix.h` that uses `CpuPriority.`
- I think `SetCpuPriority()` make sense to exist in `port_posix.h` as it provides has platform-dependent implementation
- `CpuPriority` enum is defined in `env.h`, but used in `rocksdb/include` and `port/`.
Hence, let us define `CpuPriority` enum in a common file, say `port_defs.h`, such that both directories `rocksdb/include` and `port/` can include.
When we remove this dependency, some other files have compile errors because they can't find definitions, so add header files to resolve
# Test
make all check -j
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11214
Reviewed By: pdillinger
Differential Revision: D43196910
Pulled By: guowentian
fbshipit-source-id: 70deccb72844cfb08fcc994f76c6ef6df5d55ab9
2 years ago
|
|
|
#include <functional>
|
|
|
|
#include <memory>
|
support for concurrent adds to memtable
Summary:
This diff adds support for concurrent adds to the skiplist memtable
implementations. Memory allocation is made thread-safe by the addition of
a spinlock, with small per-core buffers to avoid contention. Concurrent
memtable writes are made via an additional method and don't impose a
performance overhead on the non-concurrent case, so parallelism can be
selected on a per-batch basis.
Write thread synchronization is an increasing bottleneck for higher levels
of concurrency, so this diff adds --enable_write_thread_adaptive_yield
(default off). This feature causes threads joining a write batch
group to spin for a short time (default 100 usec) using sched_yield,
rather than going to sleep on a mutex. If the timing of the yield calls
indicates that another thread has actually run during the yield then
spinning is avoided. This option improves performance for concurrent
situations even without parallel adds, although it has the potential to
increase CPU usage (and the heuristic adaptation is not yet mature).
Parallel writes are not currently compatible with
inplace updates, update callbacks, or delete filtering.
Enable it with --allow_concurrent_memtable_write (and
--enable_write_thread_adaptive_yield). Parallel memtable writes
are performance neutral when there is no actual parallelism, and in
my experiments (SSD server-class Linux and varying contention and key
sizes for fillrandom) they are always a performance win when there is
more than one thread.
Statistics are updated earlier in the write path, dropping the number
of DB mutex acquisitions from 2 to 1 for almost all cases.
This diff was motivated and inspired by Yahoo's cLSM work. It is more
conservative than cLSM: RocksDB's write batch group leader role is
preserved (along with all of the existing flush and write throttling
logic) and concurrent writers are blocked until all memtable insertions
have completed and the sequence number has been advanced, to preserve
linearizability.
My test config is "db_bench -benchmarks=fillrandom -threads=$T
-batch_size=1 -memtablerep=skip_list -value_size=100 --num=1000000/$T
-level0_slowdown_writes_trigger=9999 -level0_stop_writes_trigger=9999
-disable_auto_compactions --max_write_buffer_number=8
-max_background_flushes=8 --disable_wal --write_buffer_size=160000000
--block_size=16384 --allow_concurrent_memtable_write" on a two-socket
Xeon E5-2660 @ 2.2Ghz with lots of memory and an SSD hard drive. With 1
thread I get ~440Kops/sec. Peak performance for 1 socket (numactl
-N1) is slightly more than 1Mops/sec, at 16 threads. Peak performance
across both sockets happens at 30 threads, and is ~900Kops/sec, although
with fewer threads there is less performance loss when the system has
background work.
Test Plan:
1. concurrent stress tests for InlineSkipList and DynamicBloom
2. make clean; make check
3. make clean; DISABLE_JEMALLOC=1 make valgrind_check; valgrind db_bench
4. make clean; COMPILE_WITH_TSAN=1 make all check; db_bench
5. make clean; COMPILE_WITH_ASAN=1 make all check; db_bench
6. make clean; OPT=-DROCKSDB_LITE make check
7. verify no perf regressions when disabled
Reviewers: igor, sdong
Reviewed By: sdong
Subscribers: MarkCallaghan, IslamAbdelRahman, anthony, yhchiang, rven, sdong, guyg8, kradhakrishnan, dhruba
Differential Revision: https://reviews.facebook.net/D50589
9 years ago
|
|
|
#include <mutex>
|
|
|
|
#include <thread>
|
|
|
|
|
|
|
|
#include "port/port.h"
|
|
|
|
#include "util/fastrange.h"
|
|
|
|
#include "util/hash.h"
|
|
|
|
|
|
|
|
namespace ROCKSDB_NAMESPACE {
|
|
|
|
|
|
|
|
// Helper class that locks a mutex on construction and unlocks the mutex when
|
|
|
|
// the destructor of the MutexLock object is invoked.
|
|
|
|
//
|
|
|
|
// Typical usage:
|
|
|
|
//
|
|
|
|
// void MyClass::MyMethod() {
|
|
|
|
// MutexLock l(&mu_); // mu_ is an instance variable
|
|
|
|
// ... some complex code, possibly with multiple return paths ...
|
|
|
|
// }
|
|
|
|
|
|
|
|
class MutexLock {
|
|
|
|
public:
|
|
|
|
explicit MutexLock(port::Mutex *mu) : mu_(mu) { this->mu_->Lock(); }
|
|
|
|
// No copying allowed
|
|
|
|
MutexLock(const MutexLock &) = delete;
|
|
|
|
void operator=(const MutexLock &) = delete;
|
|
|
|
|
|
|
|
~MutexLock() { this->mu_->Unlock(); }
|
|
|
|
|
|
|
|
private:
|
|
|
|
port::Mutex *const mu_;
|
|
|
|
};
|
|
|
|
|
|
|
|
//
|
|
|
|
// Acquire a ReadLock on the specified RWMutex.
|
|
|
|
// The Lock will be automatically released when the
|
|
|
|
// object goes out of scope.
|
|
|
|
//
|
|
|
|
class ReadLock {
|
|
|
|
public:
|
|
|
|
explicit ReadLock(port::RWMutex *mu) : mu_(mu) { this->mu_->ReadLock(); }
|
|
|
|
// No copying allowed
|
|
|
|
ReadLock(const ReadLock &) = delete;
|
|
|
|
void operator=(const ReadLock &) = delete;
|
|
|
|
|
|
|
|
~ReadLock() { this->mu_->ReadUnlock(); }
|
|
|
|
|
|
|
|
private:
|
|
|
|
port::RWMutex *const mu_;
|
|
|
|
};
|
|
|
|
|
|
|
|
//
|
|
|
|
// Automatically unlock a locked mutex when the object is destroyed
|
|
|
|
//
|
|
|
|
class ReadUnlock {
|
|
|
|
public:
|
|
|
|
explicit ReadUnlock(port::RWMutex *mu) : mu_(mu) { mu->AssertHeld(); }
|
|
|
|
// No copying allowed
|
|
|
|
ReadUnlock(const ReadUnlock &) = delete;
|
|
|
|
ReadUnlock &operator=(const ReadUnlock &) = delete;
|
|
|
|
|
|
|
|
~ReadUnlock() { mu_->ReadUnlock(); }
|
|
|
|
|
|
|
|
private:
|
|
|
|
port::RWMutex *const mu_;
|
|
|
|
};
|
|
|
|
|
|
|
|
//
|
|
|
|
// Acquire a WriteLock on the specified RWMutex.
|
|
|
|
// The Lock will be automatically released then the
|
|
|
|
// object goes out of scope.
|
|
|
|
//
|
|
|
|
class WriteLock {
|
|
|
|
public:
|
|
|
|
explicit WriteLock(port::RWMutex *mu) : mu_(mu) { this->mu_->WriteLock(); }
|
|
|
|
// No copying allowed
|
|
|
|
WriteLock(const WriteLock &) = delete;
|
|
|
|
void operator=(const WriteLock &) = delete;
|
|
|
|
|
|
|
|
~WriteLock() { this->mu_->WriteUnlock(); }
|
|
|
|
|
|
|
|
private:
|
|
|
|
port::RWMutex *const mu_;
|
|
|
|
};
|
|
|
|
|
support for concurrent adds to memtable
Summary:
This diff adds support for concurrent adds to the skiplist memtable
implementations. Memory allocation is made thread-safe by the addition of
a spinlock, with small per-core buffers to avoid contention. Concurrent
memtable writes are made via an additional method and don't impose a
performance overhead on the non-concurrent case, so parallelism can be
selected on a per-batch basis.
Write thread synchronization is an increasing bottleneck for higher levels
of concurrency, so this diff adds --enable_write_thread_adaptive_yield
(default off). This feature causes threads joining a write batch
group to spin for a short time (default 100 usec) using sched_yield,
rather than going to sleep on a mutex. If the timing of the yield calls
indicates that another thread has actually run during the yield then
spinning is avoided. This option improves performance for concurrent
situations even without parallel adds, although it has the potential to
increase CPU usage (and the heuristic adaptation is not yet mature).
Parallel writes are not currently compatible with
inplace updates, update callbacks, or delete filtering.
Enable it with --allow_concurrent_memtable_write (and
--enable_write_thread_adaptive_yield). Parallel memtable writes
are performance neutral when there is no actual parallelism, and in
my experiments (SSD server-class Linux and varying contention and key
sizes for fillrandom) they are always a performance win when there is
more than one thread.
Statistics are updated earlier in the write path, dropping the number
of DB mutex acquisitions from 2 to 1 for almost all cases.
This diff was motivated and inspired by Yahoo's cLSM work. It is more
conservative than cLSM: RocksDB's write batch group leader role is
preserved (along with all of the existing flush and write throttling
logic) and concurrent writers are blocked until all memtable insertions
have completed and the sequence number has been advanced, to preserve
linearizability.
My test config is "db_bench -benchmarks=fillrandom -threads=$T
-batch_size=1 -memtablerep=skip_list -value_size=100 --num=1000000/$T
-level0_slowdown_writes_trigger=9999 -level0_stop_writes_trigger=9999
-disable_auto_compactions --max_write_buffer_number=8
-max_background_flushes=8 --disable_wal --write_buffer_size=160000000
--block_size=16384 --allow_concurrent_memtable_write" on a two-socket
Xeon E5-2660 @ 2.2Ghz with lots of memory and an SSD hard drive. With 1
thread I get ~440Kops/sec. Peak performance for 1 socket (numactl
-N1) is slightly more than 1Mops/sec, at 16 threads. Peak performance
across both sockets happens at 30 threads, and is ~900Kops/sec, although
with fewer threads there is less performance loss when the system has
background work.
Test Plan:
1. concurrent stress tests for InlineSkipList and DynamicBloom
2. make clean; make check
3. make clean; DISABLE_JEMALLOC=1 make valgrind_check; valgrind db_bench
4. make clean; COMPILE_WITH_TSAN=1 make all check; db_bench
5. make clean; COMPILE_WITH_ASAN=1 make all check; db_bench
6. make clean; OPT=-DROCKSDB_LITE make check
7. verify no perf regressions when disabled
Reviewers: igor, sdong
Reviewed By: sdong
Subscribers: MarkCallaghan, IslamAbdelRahman, anthony, yhchiang, rven, sdong, guyg8, kradhakrishnan, dhruba
Differential Revision: https://reviews.facebook.net/D50589
9 years ago
|
|
|
//
|
|
|
|
// SpinMutex has very low overhead for low-contention cases. Method names
|
|
|
|
// are chosen so you can use std::unique_lock or std::lock_guard with it.
|
|
|
|
//
|
|
|
|
class SpinMutex {
|
|
|
|
public:
|
|
|
|
SpinMutex() : locked_(false) {}
|
|
|
|
|
|
|
|
bool try_lock() {
|
|
|
|
auto currently_locked = locked_.load(std::memory_order_relaxed);
|
|
|
|
return !currently_locked &&
|
|
|
|
locked_.compare_exchange_weak(currently_locked, true,
|
|
|
|
std::memory_order_acquire,
|
|
|
|
std::memory_order_relaxed);
|
|
|
|
}
|
|
|
|
|
|
|
|
void lock() {
|
|
|
|
for (size_t tries = 0;; ++tries) {
|
|
|
|
if (try_lock()) {
|
|
|
|
// success
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
port::AsmVolatilePause();
|
|
|
|
if (tries > 100) {
|
|
|
|
std::this_thread::yield();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void unlock() { locked_.store(false, std::memory_order_release); }
|
|
|
|
|
|
|
|
private:
|
|
|
|
std::atomic<bool> locked_;
|
|
|
|
};
|
|
|
|
|
|
|
|
// For preventing false sharing, especially for mutexes.
|
|
|
|
// NOTE: if a mutex is less than half the size of a cache line, it would
|
|
|
|
// make more sense for Striped structure below to pack more than one mutex
|
|
|
|
// into each cache line, as this would only reduce contention for the same
|
|
|
|
// amount of space and cache sharing. However, a mutex is often 40 bytes out
|
|
|
|
// of a 64 byte cache line.
|
|
|
|
template <class T>
|
|
|
|
struct ALIGN_AS(CACHE_LINE_SIZE) CacheAlignedWrapper {
|
|
|
|
T obj_;
|
|
|
|
};
|
|
|
|
template <class T>
|
|
|
|
struct Unwrap {
|
|
|
|
using type = T;
|
|
|
|
static type &Go(T &t) { return t; }
|
|
|
|
};
|
|
|
|
template <class T>
|
|
|
|
struct Unwrap<CacheAlignedWrapper<T>> {
|
|
|
|
using type = T;
|
|
|
|
static type &Go(CacheAlignedWrapper<T> &t) { return t.obj_; }
|
|
|
|
};
|
|
|
|
|
|
|
|
//
|
|
|
|
// Inspired by Guava: https://github.com/google/guava/wiki/StripedExplained
|
|
|
|
// A striped Lock. This offers the underlying lock striping similar
|
|
|
|
// to that of ConcurrentHashMap in a reusable form, and extends it for
|
|
|
|
// semaphores and read-write locks. Conceptually, lock striping is the technique
|
|
|
|
// of dividing a lock into many <i>stripes</i>, increasing the granularity of a
|
|
|
|
// single lock and allowing independent operations to lock different stripes and
|
|
|
|
// proceed concurrently, instead of creating contention for a single lock.
|
|
|
|
//
|
|
|
|
template <class T, class Key = Slice, class Hash = SliceNPHasher64>
|
|
|
|
class Striped {
|
|
|
|
public:
|
|
|
|
explicit Striped(size_t stripe_count)
|
|
|
|
: stripe_count_(stripe_count), data_(new T[stripe_count]) {}
|
|
|
|
|
|
|
|
using Unwrapped = typename Unwrap<T>::type;
|
|
|
|
Unwrapped &Get(const Key &key, uint64_t seed = 0) {
|
|
|
|
size_t index = FastRangeGeneric(hash_(key, seed), stripe_count_);
|
|
|
|
return Unwrap<T>::Go(data_[index]);
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t ApproximateMemoryUsage() const {
|
|
|
|
// NOTE: could use malloc_usable_size() here, but that could count unmapped
|
|
|
|
// pages and could mess up unit test OccLockBucketsTest::CacheAligned
|
|
|
|
return sizeof(*this) + stripe_count_ * sizeof(T);
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
size_t stripe_count_;
|
|
|
|
std::unique_ptr<T[]> data_;
|
|
|
|
Hash hash_;
|
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace ROCKSDB_NAMESPACE
|