Your SlideShare is downloading. ×
ロックフリーGCLOCKページ置換アルゴリズム
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

ロックフリーGCLOCKページ置換アルゴリズム

5,220
views

Published on

Published in: Technology

0 Comments
11 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,220
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
1
Comments
0
Likes
11
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ロックフリーGCLOCKページ置換 アルゴリズム 油井誠,宮崎純,植村俊亮,加藤博一 奈良先端科学技術大学院大学 D3 日本学術振興会特別研究員 DC2 WebDB forum 2008
  • 2. 研究背景  CPUが同時実行できるスレッド数が増加 e.g., - Niagara T2 – 8 cores x 8 SMT = 64 processors - Azul Vega2 – 48 cores x 16 chips = 768 processors  データベースのCPUスケーラビリティの問題が顕著化 代表的なオープンソースRDBMSのCPUスケーラビリティの上限 [1][2] Berkely DB – 4スレッド MySQL 5.0.30以降 – 8スレッド PostgreSQL 8.2以降 – 16スレッド [1] Ryan Johnson, Ippokratis Pandis, Anastassia Ailamaki: “Critical Sections: Re-emerging Scalability Concerns for Database Storage Engines”, In Proc. DaMoN, 2008. [2] 日本OSS 推進フォーラム: 2006 年度オープンソースソフトウェア(OSS) の性能・信頼性評価の成果 WebDB forum 2008 2
  • 3. PostreSQLのCPUスケーラビリティ Unisysの大型Linuxシステム(32プロセッサXeon-SMP環境, メモリ16Gb, EMCのRAID10ストレージ) で,TPC-Cによる評価 [3] [3] Doug Tolbert, David Strong, Johney Tsai (Unisys), “Scaling PostgreSQL on SMP Architectures”, PGCON 2007. 16CPU以上の台数効果<5% 図の出典:[3] WebDB forum 2008 3
  • 4. CPUスケーラビリティを阻害する要因  バッファ管理における同期化処理 (Synchronization)  バッファ管理におけるSynchronizationの問題 とは?  バッファ参照表のロック粒度  ページ置換ポリシの並行処理に対する耐性 WebDB forum 2008 4
  • 5. 典型的なバッファ管理の構成 N Bufferfix処理 [3] next prev 要求したページを 1 バッファフレームに固定 Hash H 近代的なDBMSではbufferfix処理は, table 必ずしもIO依存ではない 2  プリフラッシュ  ダーティなページを置換対象としない 3  ログ書き込み バッファ バッファ参照表 フレーム 置換ポリシ (LRU) バッファプール  バッファプールの参照時には,バッファ参照表に 共有ロックが取得される  ページ置換時には,バッファ管理に排他ロックが 取得される [3] Jim Gray, Andreas Reuter: “Transaction Processing : Concepts and Techniques”, Morgan Kaufmann, October 1992 WebDB forum 2008 5
  • 6. ナイーブなバッファ管理 バッファ参照表に Giant lock N next prev 1 バッファ管理への 並行アクセス Hash table H 2 3 バッファ参照表 Buffer 置換ポリシ frame (LRU) バッファプール  PostgreSQL 8.0が全くスケールしなかった要因 WebDB forum 2008 6
  • 7. Lessナイーブなバッファ管理 ハッシュバケットごとに ロックを分割 Lock Striping N Hash bucket next prev 1 バッファ管理への Hash 並行アクセス bucket H Hash bucket 2 3 Hash bucket Buffer 置換ポリシ frame (LRU) バッファプール バッファ参照表  PostgreSQL 8.1とMySQL5.0.30のバッファ管理  Jim Grayのトランザクション処理にも載っている基本  アクセスされるバケットの隔たりに弱い WebDB forum 2008 7
  • 8. Least Recently Used (LRU) アクセスがあったバッファをFIFOキューの先頭に移動する 最近最もアクセスされていない ページ 一般的に双方向リストで実現される  バッファへのヒット時にも連結リスト全体をロックする必要がある  利用頻度が考慮されない  シーケンシャルスキャンに弱い  PostgreSQL 8.1以前とMySQLはLRUを利用 WebDB forum 2008 8
  • 9. CLOCK Page Replacement LRUに近似するページ置換性能を 低いコストで実現できるアルゴリズム 1 0 0 0 1 1 On Cache Hit 0 0 単に参照ビットのフラグを 1 CLOCK 0 不可分(Atomic)に立てるだけ 0 hand 1 On Cache Replacement 0 0 CLOCK-sweep 1 0 1 0 0 0  ページヒット時にはロックが不要 0 0 1 1  ページ置換時には排他ロックが必要  PostgreSQL 8.2は2QからCLOCKに乗り換え  GCLOCKは参照ビットの代わりに参照カウントが利用され, ページの参照頻度が考慮される WebDB forum 2008 9
  • 10. LRUとCLOCKの開発史 LRUと関連する CLOCKと関連するアルゴリズム 連結リストを用いるアルゴリズム  FBR (1990, SIGMETRICS)  GCLOCK (1978, ACM TDBS)  LRU-2 (1993, SIGMOD)  CAR (2004, FAST)  2Q (1994, VLDB)  CLOCK-Pro (2005, USENIX)  SEQ (1997, SIGMETRICS)  Nb-GCLOCK (2008)  LRFU (1999, OSDI) • 既存研究の着眼点  EELRU (1999, SIGMETRICS) バッファヒット率  MQ (2001, USENIX) • 提案研究の着眼点  LIRS (2002, SIGMETRICS) 並行アクセスへの耐性  ARC (2003, FAST) WebDB forum 2008 10
  • 11. バッファ管理に残された問題  ページ置換が発生した際の並列実行性能 バッファヒット率5割のバッファ管理モジュールに平均10スレッドが 並列にアクセスするケースを考える  並行アクセスが参照局所性を下げ,バッファヒット率を低下させる  頻繁な排他ロックにより実行が直列化される N • 置換対象のページを選び, Hash バッファフレームに固定する bucket next ページを変更 prev 1 Hash • 置換リストを調整 bucket H Hash bucket 2 バッファ参照表のページ識別子 3 とバッファフレームの結び付け Hash bucket を変更 置換ポリシ バッファプール バッファ参照表 WebDB forum 2008 11
  • 12. 同期処理の並行性向上のための施策 A) ロックの粒度を細かくする  細粒度のロックはロック自体のオーバヘッドを増やすかもしれないが, ロックの競合を低減する B) 軽量なロックプロトコルを採用する  Spin lockは短時間でクリティカルセクションが開放される場合に有効 (コンテキストスイッチやOSによる再スケジューリングを防ぐことができる) 従来のデータベースはAとBの組合せでスケーラビリティの問題に対処 C) ロックの獲得を必要としないアルゴリズムを採用する  並行データ構造やノンブロッキング同期(Non-blocking synchronization) を利用する ラディカルな解決策であるノンブロッキング同期を利用した 一切のロックを取得しないスケーラブルなロックフリーのバッファ管理手法 Nb-GCLOCKを提案する WebDB forum 2008 12
  • 13. ノンブロッキング同期 複数のスレッドが共有データに,ロックをかけることなく,並行した 読み書きを行うことを可能とする手法  アトミックなCPU命令を活用  CAS (compare-and-swap) X86ではcmpxchg命令,SPARCではcas, casa命令  LL/SC (load-linked/store-conditional)  メモリバリアを活用  SFENCE (Pentium 3以降) store → storeを順序付け  LFENCE (Pentium 4以降) load → loadを順序付け  MFENCE (Pentium 4以降) 全てのメモリ操作を順序付け WebDB forum 2008 13
  • 14. ノンブロッキング・アルゴリズム  ロックフリー (Lock-free)  いくつかの処理がブロックされることなく, 有限時間で終わる  Liveness(活性)を保障  無待機 (Wait-free)  すべての処理がブロックされることなく, 有限時間で終わる  Fairness(公平性)を保障 WebDB forum 2008 14
  • 15. 提案バッファ管理手法:Nb-GCLOCK バッファ参照表とページ置換リスト(GCLOCK)をノンブロッキング同期を 用いて実現したバッファ管理手法 • バッファ参照表には既存のWait-freeハッシュ表を利用 • ロックフリー版のGCLOCK単体で有効に動作するものではない WebDB forum 2008 15
  • 16. Clock-sweep処理 6 0 4 バッファフレームが管理する変数 0 1 2 3 0  参照カウント 1 CLOCK 7  pinされている数 0 hand 1  evictされているか否か -1 2 1 3 原子的に管理する必要があり,短時間の 2 0 ロックをフレームごとに取得するのが一般的 5 9 1 -1 1 0 tryEvict pin -1 0 1 gt 1 unpin evictUnshared evicted pinned 提案手法は,値域を設定し,単一の変数を共有することで 複数の変数の更新を同期基本命令によりロックなしに実現 WebDB forum 2008 16
  • 17. 状態遷移(DFA)を用いた理由付け  CLOCK-sweepで置換するバッファフレームを決定する処理  共有データに対する複数のスレッドの読み書きがInconsistentな状態を 作らないようにDFAベースに設計 E: entry action 置換ページの決定 Fix in pool Check whether evicted swapped Evicted E: CAS value success !null E: move the clock hand 現在の位置の !evicted ! swapped evicted 検証開始 Check whether Pinned Select a frame Try to evict !evicted E: evict pinned !pinned null --refcount<=0 Try to decrement continue the refcount E: decrement E: try next entry the refcount --refcount>0 時計の針を回す 参照カウントを減らす WebDB forum 2008 17
  • 18. 並行IOによるページ読み込みと固定 提案システムはバッファフレームへのページ読み込み処理を preadシステムコールとCASを利用した楽観的IOにより行う  preadは同じファイルディスクプリタへの複数のスレッド からの並行したI/O要求を効率的に処理するシステムコール  通常のバッファ管理はio_in_progressロックを用いた 排他制御を行う lock; lseek; read; unlock WebDB forum 2008 18
  • 19. 並行IOによるページ読み込みと固定  ページを固定するバッファフレームを用意 WebDB forum 2008 19
  • 20. 並行IOによるページ読み込みと固定  volatile loadのためのメモリフェンスを張ってから ページを取得 - X86とSPARCではNop WebDB forum 2008 20
  • 21. 並行IOによるページ読み込みと固定  preadによりディスクから要求ページを読み込む  指定されたスロットにページが割り当てられていなければ updateに書き換え WebDB forum 2008 21
  • 22. 評価実験  実験データには,Zipf 80/20と45/20の分布[1]を仕様  データベースのワークロードをシュミレートするために Zipfワークロードに20%のシーケンシャルスキャンを挟んだ  バッファの容量はページ数4k, 8k, 16k, 32kを検証  マルチユーザ環境をシュミレートするために複数のスレッドが 同時にワークロードを実行する  実験環境#1はUltraSPARC T2 64ハードウェアスレッド [1] Donald E. Knuth. Art of Computer Programming, volume 3. Addison-Wesley Professional, April 1998. WebDB forum 2008 22
  • 23. 実験の前に抱いた疑問と答え Q1. Bufferfixをノンブロッキングにしても並列のIOが 発生して問題となるのでは? A1. preadシステムコールを使えば問題ない Q2. どれだけCPU-intensiveな場合に提案手法が 有効になるか? A2. これからバッファヒット率に対する性能で示す WebDB forum 2008 23
  • 24. lseek+readとpreadの性能比較  UltraSPARC T2環境でZipf 80/20のワークロードで評価  64スレッドからの並行アクセス 4,000,000 3,500,000 4096 3,000,000 8192 2,500,000 oprs/sec 16384 2,000,000 32768 1,500,000 1,000,000 500,000 0 LRU 2Q NbGClock LRU 2Q NbGClock lseek+read (lock) pread (cas) preadで発生する競合(CAS failure)の割合 競合が大きいほど,並列性が高い WebDB forum 2008 24
  • 25. ディスクIOにpreadを利用した場合  プロセッサ数に対するスケーラビリティを測定  バッファヒット率との関係を示す  提案手法は少なくともプロセッサ数に対して少なくとも対数線形の性能 3000000 LRU 2500000 2Q NbGClock(stripe) 2000000 E$NbGClock oprs/sec 1500000 1000000 500000 0 8 (1) 16 (2) 32 (4) 64 (8) 8 (1) 16 (2) 32 (4) 64 (8) processors (cores) 8192 16384 (63.1%) (75.4%) buffer capacity (buffer hit rate) WebDB forum 2008 25
  • 26. CPUスケーラビリティの上限の測定  すべてのページがメモリ内に存在する場合のCPU数に対する スケーラビリティを評価 64CPU付近まで線形に近い 30,000,000 スケーラビリティ 25,000,000 20,000,000 oprs/sec 15,000,000 10,000,000 5,000,000 0 processors (cores) 8 (1) 16 (2) 32 (4) 64 (8) LRU 702011 668649 680883 695153 2Q 648589 640807 656188 662782 ReadWriteLockは64CPUでは常に排他 CAS命令を利用した共有カウンタの NbGClock(stripe) 3358893 6391329 12686899 24883432 ロックがかかる.こうしたときはSpinlock NbGClock(atomic) 3582785 7160720 更新で,バスの競合(バスロックと 13100118 9410744 の方が複雑なロックプロトコルを採るより E$LRU 702011 1404022 キャッシュの更新)が発生 2808044 5616088 むしろ早い E$NbGClock 3358893 6717786 13435572 26871144 WebDB forum 2008 26
  • 27. 共有カウンタの問題  CPU は Out-of-order 実行 19 高速化のために load/store の順序を入れ替える - Load 命令は早く (投機実行) 18 - Store 命令は遅く (Store buffering) ナイーブな共有カウンタはStore Bufferのフラッシュ, 17 パイプラインのストールを招くためスケールしない Striped Counter  単一のカウンタ値を用いない  書き込みを複数のメモリロケーション にあるカウンタにストライプ  読み込み時に複数のカウンタ値を まとめ上げる WebDB forum 2008 27
  • 28. T2による実験後に抱いた疑問と答え Q1. UltraSPARC T2のハードウェアの特殊性に依存した アルゴリズムなのか? A1. いいえ.X86_64のSMP/ccNUMA環境においても 同様のパフォーマンスの利得が期待できます. 8スレッドにおいて既存手法に対して4~5倍の性能 WebDB forum 2008 28
  • 29. X86-64アーキテクチャにおける実験  Zipf 80/20のワークロードを利用  8スレッドからのバッファ管理モジュールへの並行アクセス  Opteron ccNUMAアーキテクチャにおいて4倍の性能  Xeon SMPアーキテクチャにおいて5倍の性能  T2の8スレッド(4.78倍の性能)と類似した性能 X86の中規模マルチプロセッサ環境にも提案手法は有効 8,000,000 7,000,000 5x 6,000,000 5,000,000 4x oprs/sec 4,000,000 3,000,000 2,000,000 1,000,000 0 LRU 2Q NbGClock Quad-core Xeon 1205061 1308776 6672930 2.5GHz x2 Dual-core Opteron 1335554 1289447 5574922 2.4GHz x4 WebDB forum 2008 29
  • 30. まとめ  ロックフリーにGCLOCKに基づくページ置換を実現する バッファ管理手法Nb-GCLOCKを提案した  バッファ管理の並行性の問題を明らかにした  楽観的な並行IOが有効に機能することがあることを明らかにした  CLOCKカウンタのストライピングの必要性を明らかにした  既存手法が16プロセッサ以上スケールしないのに対して 提案手法は64プロセッサまでほぼ線形の性能を実現可能 今後の課題  多種多様なワークロードを利用した厳密な評価 (e.g., TPC-C)  一部省略したNb-GCLOCKアルゴリズムの正当性について より詳しく述べる WebDB forum 2008 30
  • 31. ご静聴ありがとうございました アルゴリズムの詳細は論文をご覧ください WebDB forum 2008 31

×