1. Improving OLTP scalability using speculative lock inheritance Ryan Johnson, Ippokratis Pandis, Anastasia Ailamaki

2. © 2009 Ryan Johnson 2 OLTP scalability limitations Application: scalable Hardware: scalable Storage manager? –Good at interleaving threads –True concurrency is harder => Increased latch contention Contention within storage manager limits scalability

3. © 2009 Ryan Johnson 3 Contention in the lock manager Centralized service –Locks managed globally Fine-grained parallelism –Each lock has its own latch Skewed access –Some hotter than others Culprit: shared high-level locks 0 100 200 300 400 2%11%48%67%86%98% System load LM Contention Other Contention LM Overhead Computation Per-thread work breakdown

4. © 2009 Ryan Johnson 4 Contributions Identify lock manager bottleneck –Latch contention during lock state updates Eliminate most requests for hot locks –Pass hot locks directly between transactions –No changes at application level Improve throughput by 20-50%

5. © 2009 Ryan Johnson 5 In this talk… Introduction Inside the lock manager –Locking vs. latching –Lock acquire and release –Approaches for reducing overheads Speculative lock inheritance Conclusions

6. © 2009 Ryan Johnson 6 Overview of latching vs. locking Latches outnumber lock operations 5:1 or more LatchLock SerializesCode segmentsTransactions ProtectsData structuresDatabase records DurationShortLong # Held at once0-2Unbounded ImplementationStraightforwardComplex

7. © 2009 Ryan Johnson 7 Inside the lock manager - acquire Lock Manager L2 Lock Request Lock Head L1 L3 Lock ID Hash Table T1 Transaction Head Requirements  Find/create many locks in parallel  Each lock tracks many requests  Each transaction tracks many locks

8. © 2009 Ryan Johnson 8 Inside the lock manager - release Intent locks => long request chains IS S IXIS release() upgrade(IX) … … B Process upgrades C Grant new requests A Compute new lock mode (supremum) Lock strengths IS < IX < S

9. © 2009 Ryan Johnson 9 In this talk… Introduction Inside the lock manager Speculative lock inheritance –Approach and implementation –Experimental results Conclusions

10. © 2009 Ryan Johnson 10 Speculative lock inheritance Lock Manager trx 1 trx 2 trx 3 Agent thread execution Hot locks bounce between agents and LM Hot lock Cold lock

11. © 2009 Ryan Johnson 11 Speculative lock inheritance Lock Manager trx 1 trx 2 trx 3 Agent thread keeps hot locks, bypasses lock manager Agent thread execution Hot lock Cold lock

12. © 2009 Ryan Johnson 12 Criteria for lock inheritance Hot (latch contention) Held in shared mode No other trx waiting (fairness) Not row-level (too many of those) Parent (if any) also eligible

13. © 2009 Ryan Johnson 13 Avoiding starvation Held Inactive Invalid eligible && !waiting waiter arrives inherit discard Speculation is lightweight, non-intrusive Update lock requests using atomic ops  sidestep the lock manager  clean up invalid requests lazily

14. © 2009 Ryan Johnson 14 Breakdown of lock behavior row-level 34% cold 27% unused 15% missed 10% invalidated 6% exclusive 3% used 4% A few locks cause 97% of contention

15. © 2009 Ryan Johnson 15 Experimental setup Hardware –Sun T5220 “Niagara II” (sparcv9-solaris10) –16 pipelines, 64 contexts, 64GB RAM Software –Shore-MT –Extended to include lock inheritance Benchmarks (mem-resident) –Telecom: Nokia Benchmark (NDBB) –Banking: TPC-B –Online Sales: TPC-C

16. © 2009 Ryan Johnson 16 Scalability comparison Eliminate contention with low overhead 0 20 40 60 80 100 016324864 Hardware Contexts Utilized Throughput (ktps) NDBB NDBB (SLI) TPC-B (SLI) TPC-B 234% (53%) 73% (19%)

17. © 2009 Ryan Johnson 17 Impact of lock inheritance Lock bottleneck gone (but others may arise) 0% 20% 40% 60% 80% 100% Benchmark (Baseline vs. SLI) NDBBTPC-BTPC-C SLI Overhead LM Contention Other Contention LM Overhead Computation CPU time breakdown

18. © 2009 Ryan Johnson 18 Reducing overheads of locking Rdb/VMS –Distributed DBMS –Lock “carry-over” reduces network traffic DB2 “keep table lock” setting –Connection holds all table locks until close –Leads to “poor concurrency” H-Store –Single-threaded, non-interleaved execution model –No locking or latching at all

19. © 2009 Ryan Johnson 19 Conclusions All latches are potential bottlenecks –Even “fine-grained” ones if there’s skew Best solutions may be indirect –Sidestep hard problems –Look to distributed databases Lock inheritance eliminates one bottleneck –Distribute accesses to hot locks –Improve throughput 20-50% today –Benefit increases with more cores

20. © 2009 Ryan Johnson 20 Thank you!