From A to E: Analyzing TPCs OLTP Benchmarks Pınar Tözün Ippokratis Pandis* Cansu Kaynak Djordje Jevdjic Anastasia Ailamaki École Polytechnique Fédérale de Lausanne *IBM Almaden Research Center The obsolete, the ubiquitous, the unknown

OLTP Benchmarks of TPC 2 Allow fair product comparisons Drive innovations for better performance TPC-E: Unknown – Results from one DBMS vendor TPC-C: Ubiquitous – Most common TPC-A, TPC-B: Obsolete TPC-C TPC-B TPC-E TPC-A Banking Wholesale supplier Brokerage house

How is TPC-E different? 3 Hardware Storage Manager Workload Micro-architectural behavior Where does time go? Characteristics/Statistics Under-utilization due to instruction stalls Fewer cache misses and higher IPC Harder to partition requests Logical lock contention More page re-use Complex schema & transactions Longer held locks

Outline Preview Setup & Methodology Micro-architectural behavior Within the storage manager Conclusions 4

Experimental Setup ServerFat (Intel Xeon X5660)Lean (Sun Niagara T2) #Sockets21 #Cores per Socket6 (OoO)8 (in-order) #HW Contexts2464 Clock Speed2.80GHz1.40GHz Memory48GB64GB L312MB (shared)– L2256KB (per core)4MB (shared) L1-D32KB (per core)8KB (per core) L1-I32KB (per core)16KB (per core) OSUbuntu Linux kernel SunOS 5.10 Generic_

Methodology 6 Shore-MT –Scalable open-source storage manager Shore-Kits –Application layer for Shore-MT –Workloads: TPC-B, TPC-C, TPC-E, ++ Micro-architectural –Xeon X5660: Vtune, Niagara T2: cputrack –Measured at peak throughput Storage manager profiling –Niagara T2: dtrace * * *

Outline Preview Setup & Methodology Micro-architectural behavior Within the storage manager Conclusions 7

IPC on Fat & Lean Cores 8 Intel Xeon X5660Sun Niagara T2 Maximum OLTP utilizes lean cores better TPC-E has higher IPC

Execution Cycles and Stalls 9 Intel Xeon X5660 More than half of execution time goes to stalls Instruction stalls are the main problem

Cache Misses 10 TPC-E has lower data miss ratio (MPKI) L1-I misses dominate Intel Xeon X KB L1-I & 32 KB L1-D Sun Niagara T2 16KB L1-I & 8KB L1-D

Why TPC-E has lower miss ratio? 11 More scans of TPC-E Increased page reuse Average per transaction

Outline Preview Setup & Methodology Micro-architectural behavior Within the storage manager Conclusions 12

From A to E: Schema 13 branch warehouse Fixed Scaling Growing customer Increasing schema complexity TPC-BTPC-CTPC-E

From A to E: Transactions 14 TPC-BTPC-CTPC-E #Transactions1512 Transaction MixRW 100%RW 92%RW 23% Secondary Indexes None2 transactions10 transactions Transaction Input includes Branch IDWarehouse IDCustomer ID or Broker ID or Trade ID or … Harder to partition More complexity & variety in transaction mix

Within the Storage Manager 15 Sun Niagara T2 64 HW Contexts SF 64 – 0.6GB Spread SF 64 – 8.2GB Spread SF 1 – 20GB No-Spread

Within the Storage Manager 16 Sun Niagara T2 64 HW Contexts SF 64 – 0.6GB Spread SF 64 – 8.2GB Spread SF 1 – 20GB No-Spread Lock manager is the main bottleneck for TPC-E

SF 64 – 8.2GB Spread Inside the Lock Manager 17 SF 64 – 0.6GB Spread SF 1 – 20GB No-Spread Logical contention even for a large DB

Conclusions Modern hardware is still highly under-utilized –TPC-E: fewer misses, less stall time, higher IPC –OLTP utilizes less aggressive cores better Instruction footprint is too large to fit in L1-I –Spread instructions, (software guided) prefetching –Code/Compiler optimizations Logical lock contention due to hotspots –Increased complexity in schema and transactions –TPC-E: harder to physically partition –Logical partitioning, OCC 18

The obsolete The ubiquitous The unexplored Directed byProduced by Also starring: Shore-MT, Xeon X5660, Niagara T2 TPC-B TPC-C TPC-E