ASPLOS2017: Building Durable Transactions with Decoupling for Persistent Memory

1. 第2回システム系輪講会東京農工大学 D2 小柴篤史

2. 自己紹介東京農工大学大学院並木研究室 D2 ◦ http://koshiba-cs.info 研究分野 ◦ OS, システムソフトウェア ◦ CPUアーキテクチャ, ハードウェアアクセラレーション(ASIC/FPGA), メモリ管理現テーマ ◦ 次世代ハードウェア(HWアクセラレータ, 不揮発性メモリ等)を活用するシステムソフトウェア/ミドルウェアの研究 ① マルチコアアクセラレータの並列制御のための資源管理機構 ② 不揮発性メモリのソフトウェアエミュレータ 1

3. ASPLOS ’17 DudeTM: Building Durable Transactions with Decoupling for Persistent Memory Mengxing Liu, Mingxing Zhang, Kang Chen, Xuehai Quian, Yongwei Wu, Weimin Zheng, Jinglei Ren Tsinghua University, University of Southern California, Microsoft Research

4. Requirements of Durability DBやファイルシステムでは信頼性(ACID)の保証が重要 Atomicity ◦ 一度のデータ更新(Transaction)をatomicに扱う “all or nothing” Consistency ◦ データの整合性を保証する(例: 預金残高がマイナスにならない) Isolation ◦ 外部からは結果のみが見える、変更中のデータは見えない Durability ◦ Power lossやsystem crashが起きてもデータを損失しない 3

5. Persistent Memory (PM) NVMをメインメモリとして活用 ◦ DRAMと異なり電源を落としてもデータが失われない ◦ メインメモリはnon-volatileでもキャッシュはvolatile ◦ PMの書き込み中にクラッシュするとデータの不整合が生じる Crash-consistent durable transaction ◦ クラッシュから復帰するため、元データの変更前にログを取る ◦ Undo logging, Redo logging 4 Volatile Area (cache) Persistent Memory X’ Y’ Z’ writes 1 transaction X Y Z X’ Y→Y’ crash ??

6. 元のデータのログを取ってから更新 ◦ 最新のデータが常に同じ場所にある→リダイレクト等が不要課題 ◦ ログがPMへ書き込まれる(commit)ことを保証する必要がある ◦ 書き込みの度にpersist order(CLFLUSH, PCOMMIT)を発行 Volatile Area (cache) Undo logging 5 Persistent Memory X Y X Y Z Z ログ領域 X Y X Y Z Z writes 1 transaction X’ Y’ Z’ X’ Y’ Z’ →オーバヘッドに

7. 更新データをログ領域に直接書き込む ◦ persist orderをtransactionごとにまとめて行える課題 ◦ commitする前は最新のデータはログ領域に存在 ◦ commit前のデータへの参照は全てログ領域へリダイレクト Volatile Area (cache) Redo logging 6 Persistent Memory X Y X Y Z Z X’ Y’ X’ Y’ Z’ Z’ ログ領域writes 1 transaction →オーバヘッドに X’ Y’ Z’ X’ Y’ Z’

8. 更新データをログ領域に直接書き込む ◦ persist orderをtransactionごとにまとめて行える課題 ◦ commitする前は最新のデータはログ領域に存在 ◦ commit前のデータへの参照は全てログ領域へリダイレクト Volatile Area (cache) Redo logging 7 Persistent Memory X Y X Y Z Z X’ Y’ Z’ ログ領域writes 1 transaction read redirect →オーバヘッドに

9. 既存手法の問題点キャッシュをPMへ反映するタイミングが制御できない ◦ キャッシュ上のデータを自由に書き換えられない Undo logging ◦ キャッシュ上のデータがいつPMへ追い出されるか分からないため、元のデータを書き換える前にログをPMへ書き込む ⇒頻繁なpersist orderがオーバヘッドに Redo logging ◦ ログ領域に更新後のデータを直接書き込み元データを保持 ⇒元データを更新するまでリダイレクト処理がオーバヘッドに Volatileな領域への書き込みとPMへの書き込みを切り離し (decouple)、好きなタイミングで行えないか？ 8

10. 提案手法: DUDETM DUrable DEcoupled transaction system for persistent memory ◦ Shadow Memory(SM): DRAMをPMのキャッシュとして使う ◦ PMはSM/PM上のログ領域を介して更新 ⇒SM上のデータ更新とログのPersist orderを非同期に行える 9 Persistent Memory Shadow Memory cache X Y X Y Z Z X’ Y’ X’ Y’ Z’ Z’ mapping ログ領域writes 1 transaction X’ Y’ Z’ ログ領域 X’ Y’ Z’

11. Asynchronous Transaction Steps SMを用いてACID Transactionを3ステップに分割 10 (1)Perform ◦ SM上のデータ更新 ◦ Volatile redo logの生成 (2)Persist ◦ Volatile logをPMへ書き込み (3)Reproduce ◦ PM上の元データの更新 →各ステップをマルチスレッドで非同期実行

12. (1)Perform Step 各Transactionに応じてSM上のデータ更新、ログ生成 ◦ SMはTransactional Memory機能を用いてスレッド間で共有 Transactional Memory (TM)とは ◦ 共有メモリのアクセス制御手法 ◦ 全スレッドにアクセスを許可し、conflictしたらやり直し ◦ Transaction間のconsistency, isolationを保証 11 スレッド1 スレッド2 tmBegin() tmEnd() 時間 tmBegin() tmEnd() tmWrite(x) tmWrite(x) ◎ × tmBegin() ※conflict ・・・・・・ →commit →abort (やり直し) Trans. Trans.

13. (1)Perform Step Transactional MemoryライクなAPIを提供 ◦ dtmWrite : SM上のデータを更新、 volatile logを生成 ◦ dtmAbort : transaction内に保存されたログを削除 ◦ dtmEnd : ログの終わりにTransaction IDを付ける 12 1transaction →実行順序

14. (2)Persist Step SM上のログをPMへフラッシュ ◦ PersistスレッドはPerformスレッド生成時に対として生成され、バックグラウンドで実行 ◦ 各スレッドはDurable Transaction IDを更新 ◦ “これより小さいIDのTrans.はPMへフラッシュ済み”な事を表す ◦ Trans. IDがdurable IDよりも大きい場合のみフラッシュ →複数のTransactionのログフラッシュをアウトオブオーダーで処理 13

15. (2)Persist Step PMへ書き込むログのサイズを削減する手法 ◦ PMは書込み回数に制限があるため Log Combination ◦ 複数の連続したtransactionsをグループ化 ◦ グループごとのログをTrans. ID順にハッシュテーブルへ挿入 ◦ 同じアドレスへの書き込みは上書き ◦ 最後にグループ単位でログをPMへ Log Compression ◦ lz4アルゴリズムを用いてログを圧縮 ◦ クラッシュ時を除き解凍しなくてよい ◦ 圧縮前のログをSM上に保持しておけば Reproduceスレッドは直接SMを読める 14

16. (3)Reproduce Step Transaction IDの順にredo logから元データを更新 ◦ Durable IDより小さいIDを持つTransactionから順に処理 ◦ Reproduceを終えたら、ログを捨ててもいい状態に(recycle) ◦ Log combinationが適用されてる時はgroup単位でrecycle 15

17. Recovery システムクラッシュからのログの復帰 ◦ PM上のログをscanし、Reproduceされてないログを再実行 ◦ Persistが未完了のログを見つけるまでTransaction ID順に処理 ◦ 未完了のログに対応するTransactionは、復帰後のアプリケーションポリシに従って処理される(e.g., 再実行) メモリの割り当て情報の復帰 ◦ DUDETMはpmalloc/pfreeを提供、スレッドごとに各transactionで呼び出された各関数を記録 ◦ これらの関数実行のログをスレッドごとに読んで復帰 16

18. Implementation ソフトウェア実装とハードウェア実装 1. Transactional Memory ◦ ソフトウェア実装: TinySTM(http://tmware.org/tinystm) ◦ Transactional Memory用のAPIを提供するCライブラリ ◦ ハードウェア実装: Intel HaswellのRTM機能を利用 ◦ アクセス保護をハードウェアで処理 2. メモリページング ◦ ソフトウェア実装: DUDETM内に実装 ◦ DRAM上にページテーブルを置き仮想アドレスとSMのアドレスを変換 ◦ 各ページの参照数も保持し、参照されてないページからスワップ ◦ ハードウェア実装: Dune(http://dune.scs.stanford.edu/) ◦ Intel VT-xを用いてユーザプロセスにページテーブルの管理等を許可 ◦ TLBが使える 17

19. Evaluation 評価環境 ◦ 12 core Intel Xeon CPU E5-2643 v4 (3.4GHz, RTMサポート) ◦ 64GB DRAM ◦ x86-64 Linux kernel (ver. 3.16.0) ◦ 2GBのDRAMを使用(1GBずつPM、SMとして使う) PMエミューレーション ◦ PMへの書き込み時に遅延時間を挿入 ◦ 1)書き込みが1回だけ行われる場合 ◦ 現在のWriteレイテンシ = 約1μs (3500 cycles) を挿入 ◦ 将来のWriteレイテンシ =約300ns (1000 cycles) を挿入 ◦ 2) 連続して複数の書き込みが行われる場合 ◦ Max{Writeレイテンシ, (書き込みデータ量/NVMのバンド幅)}を挿入 18

20. Evaluation ベンチマーク ◦ 2種のマイクロベンチマーク(HashTable, B+-Tree) ◦ 2種のワークロード(TPC-C, TATP) ◦ TPC-CはTATPよりWrite intensive ◦ それぞれHashTableベース、B+-Treeベースの4種類を実装比較対象 ◦ (1) volatile-STM : オリジナルのTinySTM ◦ (2) DUDETM : 非同期実行、ログバッファは100万個 →ログが一杯の時はPersist stepを待つ ◦ (3) DUDETM-Inf : 非同期実行、ログバッファは無限 ◦ (4) DUDETM-Sync : SMが変更されたらすぐにPMへ書き込む →PerformとPersistを同時に行う 19

21. 評価項目 (1) Throughput ◦ DUDETMのオーバヘッド、既存研究とのスループットの比較 (2) Durable Latency ◦ データがPMに書き込まれる(Durableになる)までのレイテンシ (3) Log Optimization ◦ ログのマージ、圧縮によるPMへの書き込みの削減率 (4) Swapping Overhead ◦ SMのサイズをPMより小さくした時のページスワップのオーバヘッド (5) Scalability ◦ マルチスレッドに対するスケーラビリティ (6) HTM-based DUDETM ◦ ソフトウェア実装とハードウェア実装の性能比較 20

22. (1/6) Throughput ①DUDETMとVolatile-STMの比較 ◦ スループットの低下は7.4%～24.6% ◦ ログ生成のオーバヘッドが最も大きいため、write intensityが高いワークロードほど影響を受ける 21

23. (1/6) Throughput ②DUDETMとDUDETM-Infの比較 ◦ ログバッファの容量にかかわらず、処理性能はほぼ同じ(赤枠) ◦ ログ生成(Perform)がPMへの書き込みより遅いためバッファが埋まりにくい 22

24. (1/6) Throughput ③DUDETMとDUDETM-Syncの比較 ◦ ログフラッシュがボトルネックに→非同期実行によってスループットを改善 ◦ Transactionあたりの書き込みが多い(TPC-C)とレイテンシは影響しない 23

25. (1/6) Throughput 他のシステムとの比較 ◦ Mnemosyne(redo logging), NVML(undo logging) ◦ DUDETMは1.7～4.4倍、DUDE-Syncは1.3～3.0倍の性能向上 ◦ Mnemosyneが遅い理由 ◦ Redo loggingのaddress mapping ◦ 各Transactionが同期的にpersist処理を行う(DUDE-Syncと同じ) ◦ NVMLが遅い理由 ◦ ログ領域をTrans.ごとに確保するため (他はスレッド生成時に確保) 24 各システムのスループット (higher is better)

26. (2/6) Latency Transactionの実行開始～durableになるまでの時間 ◦ 理想値(1/DUDETMのスループット)の2倍程度 ◦ 99%のtransactionsが次のtransactionのPerform Stepが終わる前にDurableになっている ⇒Performスレッドが実行中に、バックグラウンドで動くPersistスレッドがほとんどのログフラッシュを終えている 25 HashTable-based TPC-CのDurableレイテンシ (lower is better) Durableになった transactionsの割合

27. (3/6) Log Optimization Log optimizationによるログの書込みサイズの削減率 ◦ Log Combinationは最大93%削減 ◦ ただしtransaction数を増やすとレイテンシとメモリ使用量も増加 ◦ Log Compressionは約69%削減 ◦ Persist stepのみ有効、Reproduceの書き込みは減らせない 26 1グループ当たりのTransaction数に対するログの削減率 (higher is better) YCSBのSession Store ワークロード

28. (4/6) Swapping Overhead Shadow Memoryページのスワップオーバヘッド ◦ SMのサイズとメモリアクセスの偏り(Zipf分布)を変えて評価 ◦ SMのサイズが大きい場合はハードウェア実装が有利 ◦ TLBを使えるのでページングをより高速に行える ◦ SMサイズが小さいと不利: ページフォルト時のオーバヘッドのため ⇒TLBエントリを無効化するためにVM exitを使うから 27 1スレッド当たりのスループットに対する比率 (higher is better)

29. (5/6) Scalability マルチスレッドのスケーラビリティはTinySTMと同等 ◦ TinySTMの並列制御機構がボトルネック ◦ スレッド間のconflicts発生時のオーバヘッドが大きい ◦ conflictsが起きないようにTPC-Cを変更 (conflict mitigated) ◦ スループットがほぼリニアにスケール →DUDETM本体はスケーラビリティに影響しない 28 1スレッド当たりのスループットに対する比率 (higher is better) バンド幅 : 1GB/s レイテンシ: 1000 cycles

30. (6/6) HTM-based DUDETM TMのソフトウェア実装(STM)とハードウェア実装(HTM) ◦ ハードウェア実装により最大1.7倍の性能向上 ◦ B+-Treeが最も効果が高い ◦ 1回のtransactionが長く、conflictsが起きやすいため ◦ TATPは効果が小さい ◦ 書き込み回数が少なく、conflictsが起きにくいため ◦ オーバヘッドはSTM/HTM共に28%以下→様々な環境に移植可能 29 各システムのスループット (higher is better)

31. まとめ PM環境でDurable Transactionを保証するDUDETM ◦ DRAMをPMキャッシュとして用いるShadow Memoryを提案 ◦ Shadow MemoryとTransactional Memory技術を活用して ACID transactionを3ステップに分割し非同期実行を実現 ◦ TinySTMを用いてCライブラリとして実装 →7.4%～24.6%のオーバヘッドでDurabilityを保証 ◦ Undo loggingベースなNVML、Redo loggingベースな Mnemosyneに対してそれぞれ4.4倍, 1.7倍の性能 ◦ ハードウェアのTM機能を用いてスループットを1.7倍向上 30

32. 他の発表 An Analysis of Persistent Memory Use with WHISPER ◦ DRAMとNVMのハイブリッド構成のメインメモリの性能評価用ワークロードの提案、それを用いた性能解析 Thermostat: Application-transparent Page Management for Two-tiered Main Memory ◦ Hugepageを用いたVM環境で、アクセス回数に応じて DRAM or NVMにページ割当て→性能低下を抑えコスト削減 Failure-Atomic Slotted Paging for Persistent Memory ◦ NVMをデータベースのバッファキャッシュとして用いる際にNVMへの冗長なログ書き込みやcommitを防ぐメモリ管理 31

33. 感想 NVMは産業でもホットな話題 (Intel 3D Xpoint) ◦ Intel Optane SSD http://www.intel.co.jp/content/www/jp/ja/architecture-and-technology/intel- optane-technology.html ◦ Intel Persistent Memory https://itpeernetwork.intel.com/new-breakthrough-persistent-memory-first-public-demo/ NVMの特性をどうやって活用/隠蔽するか ◦ 不揮発性、耐久性の違い ◦ 価格の違い(DRAMより安くて大容量) ◦ レイテンシの違い(DRAMより遅い、WriteがReadより遅い) ◦ エネルギーの違い(待機電力は小さいけど、書き込みは大きい) どのようにユーザに提供するか ◦ ライブラリ？OS/VMMレイヤで提供？ハードウェア？ 32 まだまだ研究ネタは多い！(と思います)

ASPLOS2017: Building Durable Transactions with Decoupling for Persistent Memory

You are reading a preview.

Check these out next

ASPLOS2017: Building Durable Transactions with Decoupling for Persistent Memory

More Related Content

Slideshows for you (20)

Similar to ASPLOS2017: Building Durable Transactions with Decoupling for Persistent Memory (20)

Recently uploaded (20)

ASPLOS2017: Building Durable Transactions with Decoupling for Persistent Memory