• N
    support for concurrent adds to memtable · 7d87f027
    Nathan Bronson 提交于
    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
    7d87f027
src.mk 21.0 KB