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以上の台数効果<５%
図の出典:[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
 ログ書き込み バッファ
バッファ参照表 フレーム
置換ポリシ
（ＬＲＵ） バッファプール
 バッファプールの参照時には，バッファ参照表に
共有ロックが取得される
 ページ置換時には，バッファ管理に排他ロックが
取得される
[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
（ＬＲＵ） バッファプール
 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
（ＬＲＵ） バッファプール
バッファ参照表
 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
３ 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スレッドにおいて既存手法に対して４～５倍の性能
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