Mostly-Optimistic Concurrency Control for Highly Contended Dynamic - PowerPoint PPT Presentation

Mostly-Optimistic Concurrency Control for Highly Contended Dynamic Workloads on 1000 cores Tianzheng Wang , University of Toronto Hideaki Kimura*, Hewlett Packard Labs * Currently with Oracle

OLTP on modern & future hardware Multi-socket HPE Superdome X 16 sockets, 576 HW threads Tens of cores CRAY XC with HPE Knights The Machine Landing Very high parallelism Need lightweight concurrency control (CC) 2

Modern Optimistic CC 101 1. Local R/W 2. Verify 3. Commit/abort A B Database Transaction 1 Transaction 2 Read set: { A, B } Read set: { A, B } Write set: { A’ } Write set: { B’ } Read A Read A Read B Lock(B) Read B Write B’ A, B changed? Time Write A’ Commit B = B’ Unlock(B) Commit? Lock(A) A, B changed? Unlock(A) Abort 3

Why does OCC work well? Only lock writes  No shared memory writes for reads Only lock at commit time Sort writes before locking  No deadlock possible Simplifies lock implementation 4

High contention: OCC doesn’t work – 256 threads + 50 records YCSB, 10 ops/tx > 98% aborts Reads not protected 5

Mostly -Optimistic Concurrency Control Key idea: protect hot records with locks High-cont.: 2PL good at MOCC: best(2PL) + best(OCC) Low contention: OCC good at Only lock hot records (keep OCC’s benefits) Must lock as of the access Need better locks Could New sync. deadlock primitive 6

Must only lock hot records – Read-only , 256 threads Interconnect flooded 7

Less physical contention with approximate counter* Real temperature Page ~= 2 pTemp pTemp Increment upon abort A B … with prob. = 1/ 2 pTemp Reduces cache line invalidation Easy to tell really hot records/pages Saves space * R. Morris. Counting large numbers of events in small registers. C ACM 1978 8

Lock(hot) re-introduces deadlocks A B Hot records Transaction 1 Transaction 2 Read set: { B } Read set: { A } Write set: { A’ } Write set: { B’ } X-Lock( A ) X-Lock( B ) Write A Write B Time Read B Read A S-Lock( A ) S-Lock( B ) - Wait for T1 - Wait for T2 Worse: no control over application footprint 9

Problem: locks acquired out-of-order i.e., Some locks acquired too early X-Lock( B ) Write B Read A Time S-Lock( A ) - Wait for T1 What if T2 Unlock(B) now? 10

Canonical mode (CM): All locks acquired in order Alphabetical , address… Goal: keep transaction in canonical mode Problems 1. Restore canonical mode 2. Maintain canonical mode on retry 11

Restore canonical mode Read A Unlock C Read C Lock(B) Transaction 1 Read B Read set: { A, C } … Time Write set: {} Non- Locks held: {A, C} twophase Breaking canonical mode Verify A, B, C Commit Non-twophase locking + OCC verification 12

Retrospective lock list: A safety net upon retry Keep the footprint and lock at retry Read A 1st run Read C Read set: { A, C } Read B Time Write set: {} Abort Locks held: {A, C} Retry Read set: {} Write set: {} Locks held: {} Retro. list: {A, B, C} 13

Retrospective lock list: A safety net upon retry Keep the footprint and lock at retry Read A 1st run Read C Read set: { A, C } Read B Time Write set: {} Abort Locks held: {A, C} Read(A) – Check RLL, Lock A Retry Lock( C )? Check RLL Read set: { A, B, C } … Lock B Write set: {} Lock C Locks held: {} Retro. list: {A, B, C} No risk of deadlock 14

Native locking – No centralized lock tables or blocking – Synchronization primitive directly as database locks – MOCC queuing lock = MCS RW + MCS timeout 15

Evaluation – HW: four machines of varying scale Model EB840 Z820 DL580 GryphonHawk Sockets 1 2 4 16 Cores (HT) 2 (4) 16 (32) 60 (120) 288 (576) Frequency 1.9 GHz 3.4 GHz 2.8 GHz 2.5 GHz – YCSB for high contention workloads – 10 random RMWs, vary # of writes, 50 records – More results/CC schemes in the paper – TPC-C: few conflicts  same as OCC 16

MOCC keeps the best of OCC Read-only YCSB 110MTPS 0.65MTPS 17

Keeps away the worst of OCC Read-write YCSB ~50% abort >98% abort Too many deadlocks 18

TPC-C results – Aggregate of all transactions Almost no overhead under low contention 19

Robust CC needed for OLTP Mostly-optimistic concurrency control = best(2PL) + best(OCC) Protect hot records with locks 1. Approx. counter for temperature 2. Non-twophase lock + retrospective lock list 3. MOCC queuing lock Find out more in our paper and code repo https://github.com/HewlettPackard/foedus_code Thank you! 20