Transcript Critical Sections: Re-emerging Concerns for DBMS

Critical Sections: Re-emerging
Concerns for DBMS
Ryan Johnson
Ippokratis Pandis
Anastasia Ailamaki
Carnegie Mellon University
École Polytechnique Féderale de Lausanne
A Convergence of Trends
 OLTP fits in memory[stonebraker07]
– 256GB RAM = 80M TPC-C customers
– Amazon.com had 30M customers in 2005
 Multi-core computing
– Dozens of HW contexts per chip today
– Expect 2x more cores each generation
Scalability concerns replace I/O bottleneck
© 2008 Ryan Johnson
Potential Scalability Bottlenecks
Applications
DBMS
Hardware

??

© 2008 Ryan Johnson
DBMS Scalability Comparison
Lower
DBMS "X"
Postgres
Time/trx (usec)
is better
1000
900
800
700
600
500
400
300
200
100
0
MySQL
BerkeleyDB
Shore
Sun T2000
32 HW threads
0
8
16
Threads
24
32
Insert-only
microbenchmark
Current engines face internal scalability challenges
© 2008 Ryan Johnson
Contributions
 Evaluate common synchronization

approaches, identify most useful ones
Highlight performance impact of tuning
database engines for scalability
© 2008 Ryan Johnson
Outline





Introduction
Scalability and Critical Sections
Synchronization Techniques
Shore-MT
Conclusion
© 2008 Ryan Johnson
Sources of Serialization

Concurrency control
– Serialize conflicting logical transactions
– Enforce consistency and isolation

Latching
– Serialize physical page updates
– Protect page integrity

Critical sections (semaphores)
– Serialize internal data structure updates
– Protect data structure integrity
Critical sections largely overlooked
© 2008 Ryan Johnson
Critical Sections in DBMS
 Fine-grained parallelism vital to scalability
 Transactions require tight synchronization
– Many short critical sections
– Most uncontended, some heavily contended
 TPC-C Payment
– Accesses 4-6 records
– Enters ~100 critical sections in Shore
Cannot ignore critical section performance
© 2008 Ryan Johnson
Example: Index Probe
Time
Locks
Latches
Critical
Sections
Many short critical sections per operation
© 2008 Ryan Johnson
Outline





Introduction
Scalability and Critical Sections
Synchronization Techniques
Shore-MT
Conclusion
© 2008 Ryan Johnson
Related Work
 Concurrency control
– Locking [got92]
– BTrees [moh90]
– Often assumes single hardware context
 Latching
– “Solved problem” [agr87]
– Table-based latching [got92]
 Synchronization Techniques
© 2008 Ryan Johnson
Lock-based Synchronization
Blocking Mutex
 Simple to use
 Overhead, unscalable
Test and set Spinlock
 Efficient
 Unscalable
Queue-based spinlock
 Scalable
 Mem. management
Reader-writer lock
 Concurrent readers  Overhead
© 2008 Ryan Johnson
Lock-free Synchronization
Optimistic Concurrency Control (OCC)
 No read overhead
 Writes cause livelock
Atomic Updates
 Efficient
 Limited applicability
Lock-free Algorithms
 Scalable
 Special-purpose algs
Hardware Approaches (e.g. transactional memory)
 Efficient, scalable
 Not widely available
© 2008 Ryan Johnson
Experimental Setup
 Hardware
– Sun T2000 “Niagara” server
– 8 cores, 4 threads each (32 total)
 Microbenchmark:
while(!timout_flag)
delay_ns(t_out);
acquire();
delay_ns(t_in);
release();
© 2008 Ryan Johnson
Critical Section Overhead
Scalability vs. Duration
Cost/Iteration (nsec)
800
600
ideal
tatas
mcs
ppmcs
pthread
400
200
t_out = t_in
0
0
100
200
Duration (nsec)
300
16 threads
DBMS Critical Sections
Critical sections are 60-90% overhead
© 2008 Ryan Johnson
Scalability Under Contention
Scalability vs. Contention
Cost/Iteration (nsec)
800
ideal
tatas
600
mcs
400
ppmcs
pthread
200
0
0
8
16
Threads
24
32
t_out = t_in = 0ns
TATAS or MCS best depending on contention
© 2008 Ryan Johnson
Reader-writer Performance
800
DBMS spans gamut
Cost/iteration (nsec)
ideal
tatas
mcs
tatas_rwlock
mcs_rwlock
occ
600
400
200
0
1
10
Reads/Write (avg.)
100
t_out = t_in = 100ns
16 threads
Reader-writer locks too expensive to be useful
© 2008 Ryan Johnson
Selecting a Primitive
Uncontended
Long
TAS
Mutex
Read-mostly
OCC
MCS
OCC
Short
Contended
Lock-free
A handful of primitives covers most cases
© 2008 Ryan Johnson
Outline





Introduction
Scalability and Critical Sections
Synchronization Techniques
Shore-MT
Conclusion
© 2008 Ryan Johnson
Alleviating Contention
 Modify algorithms
– Shrink/distribute/eliminate critical sections
– Fundamental scalability improvements
 Tune existing critical sections
– Reduce overheads
– Straightforward and localized changes
Both approaches vital for scalability
© 2008 Ryan Johnson
From Shore to Shore-MT
Throughput (tps)
300
baseline
dist-bpool
tune-locks
malloc
log2
lockm
bpool2
final
ideal
100
30
10
3
1
0
8
16
24
32
Concurrent Threads
Tuning and algorithmic changes at each step
© 2008 Ryan Johnson
Conclusions
 Only a few types of primitives useful
 Algorithms and tuning both essential to

performance/scalability
Open issues
– Developing ever-finer grained algorithms
– Reduce synchronization overhead
– Improve usability of reader-writer locks
– Efficient lock-free algorithms
Plenty of room for improvements by future research
© 2008 Ryan Johnson
Bibliography




[agr87] R. Agrawal, M. Carey, and M. Livoy.
“Concurrency Control Performance Modeling:
Alternatives and Implications.” In ACM ToDS, 12(4):609654, 1987.
[car94] M. Carey, et al. “Shoring up persistent
applications.” SIGMOD Record 23(2):383-394, 1994.
[got92] V. Gottemukkala and T. Lehman, “Locking and
Latching in a Memory-Resident Database System.” In
proc. VLDB’92.
[moh90] C. Mohan, “Commit-LSN: A novel and simple
method for reducing locking and latching in transaction
processing system.” In proc. VLDB’90.
© 2008 Ryan Johnson
Thank You!
© 2008 Ryan Johnson