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

Potential Scalability Bottlenecks Applications ü DBMS ?? Hardware ü

Lower is better DBMS Scalability Comparison Sun T2000 32 HW threads Insert-only microbenchmark Current engines face internal scalability challenges

Contributions • Evaluate common synchronization approaches, identify most useful ones • Highlight performance impact of tuning database engines for scalability

Outline • Introduction • Scalability and Critical Sections • Synchronization Techniques • Shore-MT • Conclusion

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

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

Time Example: Index Probe Locks Latches Critical Sections Many short critical sections per operation

Related Work • Concurrency control • Locking [got92] • BTrees [moh90] • Often assumes single hardware context • Latching • “Solved problem” [agr87] • Table-based latching [got92] • Synchronization Techniques

Lock-based Synchronization

Lock-free Synchronization

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();

DBMS Critical Sections Critical Section Overhead t_out = t_in 16 threads Critical sections are 60-90% overhead

Scalability Under Contention t_out = t_in = 0ns TATAS or MCS best depending on contention

DBMS spans gamut Reader-writer Performance t_out = t_in = 100ns 16 threads Reader-writer locks too expensive to be useful

Selecting a Primitive Uncontended Long TAS Mutex Read-mostly OCC MCS OCC Short Lock-free Contended A handful of primitives covers most cases

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

From Shore to Shore-MT 300 baseline dist-bpool 100 tune-locks malloc 30 Throughput (tps) log2 lockm 10 bpool2 final 3 ideal 1 0 8 16 24 32 Concurrent Threads Tuning and algorithmic changes at each step

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

Bibliography • [agr87] R. Agrawal, M. Carey, and M. Livoy. “Concurrency Control Performance Modeling: Alternatives and Implications.” In ACM ToDS, 12(4):609-654, 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.

Thank You!

Critical Sections: Re-emerging Concerns for DBMS