Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (17)
Similar a ASPLOS2017: Building Durable Transactions with Decoupling for Persistent Memory
Similar a ASPLOS2017: Building Durable Transactions with Decoupling for Persistent Memory (20)
Último
Último (11)
ASPLOS2017: Building Durable Transactions with Decoupling for Persistent Memory
- 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 まだまだ研究ネタは多い！(と思います)