1 / 53

Exploiting Distributed Version Concurrency in a Transactional Memory Cluster

Exploiting Distributed Version Concurrency in a Transactional Memory Cluster. Kaloian Manassiev, Madalin Mihailescu and Cristiana Amza University of Toronto, Canada. Transactional Memory Programming Paradigm. Each thread executing a parallel region: Announces start of a transaction

amal
Download Presentation

Exploiting Distributed Version Concurrency in a Transactional Memory Cluster

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Exploiting Distributed Version Concurrency in a Transactional Memory Cluster Kaloian Manassiev, Madalin Mihailescu and Cristiana Amza University of Toronto, Canada

  2. Transactional Memory Programming Paradigm Each thread executing a parallel region: • Announces start of a transaction • Executes operations on shared objects • Attempts to commit the transaction • If no data race, commit succeeds, operations take effect • Otherwise commit fails, operations discarded, transaction restarted • Simpler than locking!

  3. Transactional Memory • Used in multiprocessor platforms • Our work: the first TM implementation on a cluster • Supports both SQL and parallel scientific applications (C++)

  4. TM in a Multiprocessor Node T1: Active Copy of A T2: Active A T2: Write(A) T1: Read(A) • Multiple physical copies of data • High memory overhead

  5. TM on a ClusterKey Idea 1. Distributed Versions • Different versions of data arise naturally in a cluster • Create new version on different node, others read own versions read write read read

  6. Exploiting Distributed Page Versions Distributed Transactional Memory (DTM) network mem0 v3 mem1 v2 mem2 v1 memN v0 ... txn0 txn1 txn2 txnN

  7. v1 v1 v2 v2 v2 v2 Key Idea 2: Concurrent “Snapshots” Inside Each Node Txn1 (v2) Txn0 (v1) read

  8. v1 v1 v1 v1 v2 v2 v2 v2 v2 v2 v2 v2 Key Idea 2: Concurrent “Snapshots” Inside Each Node Txn1 (v2) Txn0 (v1) read

  9. v1 v1 v1 v1 v2 v1 v2 v2 v2 v2 v2 v2 Key Idea 2: Concurrent “Snapshots” Inside Each Node Txn1 (v2) Txn0 (v1) read

  10. Distributed Transactional Memory A novel fine-grained distributed concurrency control algorithm • Low memory overhead • Exploits distributed versions • Supports multithreading within the node • Provides 1-copy serializability

  11. Outline • Programming Interface • Design • Data access tracking • Data replication • Conflict resolution • Experiments • Related work and Conclusions

  12. Programming Interface • init_transactions() • begin_transaction() • allocate_dtmemory() • commit_transaction() • Need to declare TM variables explicitly

  13. Data Access Tracking • DTM traps reads and writes to shared memory by either one of: • Virtual memory protection • Classic page-level memory protection technique • Operator overloading in C++ • Trapping reads: conversion operator • Trapping writes: assignment ops (=, +=, …) & increment/decrement(++/--)

  14. Data Replication T1(UPDATE) Page 1 Page 1 Page 2 Page 2 …… …… Page n Page n

  15. Twin Creation Wr p1 T1(UPDATE) P1 Twin Page 1 Page 1 Page 2 Page 2 …… …… Page n Page n

  16. Twin Creation Wr p2 T1(UPDATE) P1 Twin Page 1 Page 1 P2 Twin Page 2 Page 2 …… …… Page n Page n

  17. Diff Creation T1(UPDATE) Page 1 Page 1 Page 2 Page 2 …… …… Page n Page n

  18. Broadcast of the Modifications at Commit Latest Version = 7 Latest Version = 7 T1(UPDATE) Page 1 Page 1 Diff broadcast (vers 8) v2 v1 Page 2 Page 2 v1 …… …… Page n Page n

  19. Other Nodes Enqueue Diffs Latest Version = 7 Latest Version = 7 T1(UPDATE) Page 1 Page 1 Diff broadcast (vers 8) v8 v2 v1 Page 2 Page 2 v8 v1 …… …… Page n Page n

  20. Update Latest Version Latest Version = 7 Latest Version = 8 T1(UPDATE) Page 1 Page 1 v8 v2 v1 Page 2 Page 2 v8 v1 …… …… Page n Page n

  21. Other Nodes Acknowledge Receipt Latest Version = 7 Latest Version = 8 T1(UPDATE) Page 1 Page 1 Ack (vers 8) v8 v2 v1 Page 2 Page 2 v8 v1 …… …… Page n Page n

  22. T1 Commits Latest Version = 8 Latest Version = 8 T1(UPDATE) Page 1 Page 1 v8 v2 v1 Page 2 Page 2 v8 v1 …… …… Page n Page n

  23. Lazy Diff Application Latest Version = 8 T2(V2): Rd(…, P1, P2) V0 Page 1 V8 V2 V1 V0 Page 2 V8 V1 . . . V3 Page N V5 V4

  24. Lazy Diff Application Latest Version = 8 T2(V2): Rd(…, P1, P2) V2 Page 1 V8 V0 Page 2 V8 V1 . . . V3 Page N V5 V4

  25. Lazy Diff Application Latest Version = 8 T2(V2): Rd(…, P1, P2) V2 Page 1 V8 V1 Page 2 V8 . . . V3 Page N V5 V4

  26. Lazy Diff Application Latest Version = 8 T2(V2): Rd(…, P1, P2) V2 Page 1 V8 V1 Page 2 V8 . . . V3 Page N T3(V8): Rd(PN) V5 V4

  27. Lazy Diff Application Latest Version = 8 T2(V2): Rd(…, P1, P2) V2 Page 1 V8 V1 Page 2 V8 . . . V5 Page N T3(V8): Rd(PN)

  28. Waiting Due to Conflict Latest Version = 8 T2(V2): Rd(…, P1, P2) V2 Page 1 V8 V1 Wait until T2 commits Page 2 V8 . . . V5 Page N T3(V8): Rd(PN, P2)

  29. Transaction Abort Due to Conflict Latest Version = 8 T2(V2): Rd(…, P1, P2) V2 Page 1 V8 V0 Page 2 V8 V1 . . . V3 Page N T3(V8): Rd(P2) V5 V4

  30. Transaction Abort Due to Conflict Latest Version = 8 T2(V2): Rd(…, P1, P2) V2 Page 1 V8 V8 Page 2 CONFLICT! . . . V3 Page N T3(V8): Rd(P2) V5 V4

  31. Write-Write Conflict Resolution • Can be done in two ways • Executing all updates on a master node, which enforces serialization order OR • Aborting the local update transaction upon receiving a conflicting diff flush • More on this in the paper

  32. Experimental Platform • Cluster of Dual AMD Athlon Computers • 512 MB RAM • 1.5GHz CPUs • RedHat Fedora Linux OS

  33. Benchmarks for Experiments • TPC-W e-commerce benchmark • Models an on-line book store • Industry-standard workload mixes • Browsing (5% updates) • Shopping (20% updates) • Ordering (50% updates) • Database size of ~600MB • Hash-table micro-benchmark (in paper)

  34. Application of DTM for E-Commerce

  35. Application of DTM for E-Commerce We use a Transactional Memory Cluster as the DB Tier

  36. Cluster Architecture

  37. Implementation Details • We use MySQL’s in-memory HEAP tables • RB-Tree main-memory index • No transactional properties • Provided by inserting TM calls • Multiple threads running on each node

  38. Baseline for Comparison • State-of-the-art Conflict-aware protocol for scaling e-commerce on clusters • Coarse grained (per-table) concurrency control (USITS’03, Middleware’03)

  39. Throughput Scaling

  40. Fraction of Aborted Transactions

  41. Comparison (browsing)

  42. Comparison (shopping)

  43. Comparison (ordering)

  44. Related Work • Distributed concurrency control for database applications • Postgres-R(SI), Wu and Kemme (ICDE’05) • Ganymed, Plattner and Alonso (Middleware’04) • Distributed object stores • Argus (’83), QuickStore (’94), OOPSLA’03 • Distributed Shared Memory • TreadMarks, Keleher et al. (USENIX’94) • Tang et al. (IPDPS’04)

  45. Conclusions • New software-only transactional memory scheme on a cluster • Both strong consistency and scaling • Fine-grained distributed concurrency control • Exploits distributed versions, low memory overheads • Improved throughput scaling for e-commerce web sites

  46. Questions?

  47. Backup slides

  48. Example Program #include <dtm_types.h> typedef struct Point { dtm_int x; dtm_int y; } Point; init_transactions(); for (int i = 0; i < 10; i++) { begin_transaction(); Point * p = allocate_dtmemory(); p->x = rand(); p->y = rand(); commit_transaction(); }

  49. Query weights

  50. Decreasing the fraction of aborts

More Related