Suche senden
Hochladen
ロックフリーGCLOCKページ置換アルゴリズム
•
14 gefällt mir
•
4,161 views
Makoto Yui
Folgen
Technologie
Melden
Teilen
Melden
Teilen
1 von 31
Empfohlen
トランザクション処理可能な分散DB 「YugabyteDB」入門(Open Source Conference 2022 Online/Fukuoka 発...
トランザクション処理可能な分散DB 「YugabyteDB」入門(Open Source Conference 2022 Online/Fukuoka 発...
NTT DATA Technology & Innovation
B-link-tree
B-link-tree
Makoto Yui
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
Hironobu Suzuki
pg_walinspectについて調べてみた!(第37回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_walinspectについて調べてみた!(第37回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
Deflate
Deflate
7shi
不揮発性メモリ(PMEM)を利用したストレージエンジンの話 #mysql_jp #myna会 #yahoo #mysql #pmem #不揮発性メモリ
不揮発性メモリ(PMEM)を利用したストレージエンジンの話 #mysql_jp #myna会 #yahoo #mysql #pmem #不揮発性メモリ
Yahoo!デベロッパーネットワーク
区間分割の仕方を最適化する動的計画法 (JOI 2021 夏季セミナー)
区間分割の仕方を最適化する動的計画法 (JOI 2021 夏季セミナー)
Kensuke Otsuki
ウェーブレット木の世界
ウェーブレット木の世界
Preferred Networks
Empfohlen
トランザクション処理可能な分散DB 「YugabyteDB」入門(Open Source Conference 2022 Online/Fukuoka 発...
トランザクション処理可能な分散DB 「YugabyteDB」入門(Open Source Conference 2022 Online/Fukuoka 発...
NTT DATA Technology & Innovation
B-link-tree
B-link-tree
Makoto Yui
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
Hironobu Suzuki
pg_walinspectについて調べてみた!(第37回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_walinspectについて調べてみた!(第37回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
Deflate
Deflate
7shi
不揮発性メモリ(PMEM)を利用したストレージエンジンの話 #mysql_jp #myna会 #yahoo #mysql #pmem #不揮発性メモリ
不揮発性メモリ(PMEM)を利用したストレージエンジンの話 #mysql_jp #myna会 #yahoo #mysql #pmem #不揮発性メモリ
Yahoo!デベロッパーネットワーク
区間分割の仕方を最適化する動的計画法 (JOI 2021 夏季セミナー)
区間分割の仕方を最適化する動的計画法 (JOI 2021 夏季セミナー)
Kensuke Otsuki
ウェーブレット木の世界
ウェーブレット木の世界
Preferred Networks
LakeTahoe
LakeTahoe
Yahoo!デベロッパーネットワーク
PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例
kazuhcurry
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
NTT DATA Technology & Innovation
PostgreSQLレプリケーション徹底紹介
PostgreSQLレプリケーション徹底紹介
NTT DATA OSS Professional Services
WSDM2018Study
WSDM2018Study
正志 坪坂
pg_standbyの今後について(第19回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_standbyの今後について(第19回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
YugabyteDBの実行計画を眺める(NewSQL/分散SQLデータベースよろず勉強会 #3 発表資料)
YugabyteDBの実行計画を眺める(NewSQL/分散SQLデータベースよろず勉強会 #3 発表資料)
NTT DATA Technology & Innovation
Inside vacuum - 第一回PostgreSQLプレ勉強会
Inside vacuum - 第一回PostgreSQLプレ勉強会
Masahiko Sawada
トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2
Takashi Hoshino
Wireshark入門(2)
Wireshark入門(2)
彰 村地
RSA暗号運用でやってはいけない n のこと #ssmjp
RSA暗号運用でやってはいけない n のこと #ssmjp
sonickun
冬のLock free祭り safe
冬のLock free祭り safe
Kumazaki Hiroki
プログラミングコンテストでのデータ構造 2 ~平衡二分探索木編~
プログラミングコンテストでのデータ構造 2 ~平衡二分探索木編~
Takuya Akiba
明日使えないすごいビット演算
明日使えないすごいビット演算
京大 マイコンクラブ
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
双対性
双対性
Yoichi Iwata
文献調査をどのように行うべきか?
文献調査をどのように行うべきか?
Yuichi Goto
Elmで始めるFunctional Reactive Programming
Elmで始めるFunctional Reactive Programming
Yasuyuki Maeda
レコメンドエンジン作成コンテストの勝ち方
レコメンドエンジン作成コンテストの勝ち方
Shun Nukui
プログラミングコンテストでの乱択アルゴリズム
プログラミングコンテストでの乱択アルゴリズム
Takuya Akiba
Apache Hivemall and my OSS experience
Apache Hivemall and my OSS experience
Makoto Yui
Introduction to Apache Hivemall v0.5.2 and v0.6
Introduction to Apache Hivemall v0.5.2 and v0.6
Makoto Yui
Weitere ähnliche Inhalte
Was ist angesagt?
LakeTahoe
LakeTahoe
Yahoo!デベロッパーネットワーク
PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例
kazuhcurry
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
NTT DATA Technology & Innovation
PostgreSQLレプリケーション徹底紹介
PostgreSQLレプリケーション徹底紹介
NTT DATA OSS Professional Services
WSDM2018Study
WSDM2018Study
正志 坪坂
pg_standbyの今後について(第19回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_standbyの今後について(第19回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
YugabyteDBの実行計画を眺める(NewSQL/分散SQLデータベースよろず勉強会 #3 発表資料)
YugabyteDBの実行計画を眺める(NewSQL/分散SQLデータベースよろず勉強会 #3 発表資料)
NTT DATA Technology & Innovation
Inside vacuum - 第一回PostgreSQLプレ勉強会
Inside vacuum - 第一回PostgreSQLプレ勉強会
Masahiko Sawada
トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2
Takashi Hoshino
Wireshark入門(2)
Wireshark入門(2)
彰 村地
RSA暗号運用でやってはいけない n のこと #ssmjp
RSA暗号運用でやってはいけない n のこと #ssmjp
sonickun
冬のLock free祭り safe
冬のLock free祭り safe
Kumazaki Hiroki
プログラミングコンテストでのデータ構造 2 ~平衡二分探索木編~
プログラミングコンテストでのデータ構造 2 ~平衡二分探索木編~
Takuya Akiba
明日使えないすごいビット演算
明日使えないすごいビット演算
京大 マイコンクラブ
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
双対性
双対性
Yoichi Iwata
文献調査をどのように行うべきか?
文献調査をどのように行うべきか?
Yuichi Goto
Elmで始めるFunctional Reactive Programming
Elmで始めるFunctional Reactive Programming
Yasuyuki Maeda
レコメンドエンジン作成コンテストの勝ち方
レコメンドエンジン作成コンテストの勝ち方
Shun Nukui
プログラミングコンテストでの乱択アルゴリズム
プログラミングコンテストでの乱択アルゴリズム
Takuya Akiba
Was ist angesagt?
(20)
LakeTahoe
LakeTahoe
PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
PostgreSQLレプリケーション徹底紹介
PostgreSQLレプリケーション徹底紹介
WSDM2018Study
WSDM2018Study
pg_standbyの今後について(第19回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_standbyの今後について(第19回PostgreSQLアンカンファレンス@オンライン 発表資料)
YugabyteDBの実行計画を眺める(NewSQL/分散SQLデータベースよろず勉強会 #3 発表資料)
YugabyteDBの実行計画を眺める(NewSQL/分散SQLデータベースよろず勉強会 #3 発表資料)
Inside vacuum - 第一回PostgreSQLプレ勉強会
Inside vacuum - 第一回PostgreSQLプレ勉強会
トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2
Wireshark入門(2)
Wireshark入門(2)
RSA暗号運用でやってはいけない n のこと #ssmjp
RSA暗号運用でやってはいけない n のこと #ssmjp
冬のLock free祭り safe
冬のLock free祭り safe
プログラミングコンテストでのデータ構造 2 ~平衡二分探索木編~
プログラミングコンテストでのデータ構造 2 ~平衡二分探索木編~
明日使えないすごいビット演算
明日使えないすごいビット演算
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
双対性
双対性
文献調査をどのように行うべきか?
文献調査をどのように行うべきか?
Elmで始めるFunctional Reactive Programming
Elmで始めるFunctional Reactive Programming
レコメンドエンジン作成コンテストの勝ち方
レコメンドエンジン作成コンテストの勝ち方
プログラミングコンテストでの乱択アルゴリズム
プログラミングコンテストでの乱択アルゴリズム
Mehr von Makoto Yui
Apache Hivemall and my OSS experience
Apache Hivemall and my OSS experience
Makoto Yui
Introduction to Apache Hivemall v0.5.2 and v0.6
Introduction to Apache Hivemall v0.5.2 and v0.6
Makoto Yui
Introduction to Apache Hivemall v0.5.0
Introduction to Apache Hivemall v0.5.0
Makoto Yui
Idea behind Apache Hivemall
Idea behind Apache Hivemall
Makoto Yui
Introduction to Apache Hivemall v0.5.0
Introduction to Apache Hivemall v0.5.0
Makoto Yui
What's new in Hivemall v0.5.0
What's new in Hivemall v0.5.0
Makoto Yui
What's new in Apache Hivemall v0.5.0
What's new in Apache Hivemall v0.5.0
Makoto Yui
Revisiting b+-trees
Revisiting b+-trees
Makoto Yui
Incubating Apache Hivemall
Incubating Apache Hivemall
Makoto Yui
Hivemall meets Digdag @Hackertackle 2018-02-17
Hivemall meets Digdag @Hackertackle 2018-02-17
Makoto Yui
Apache Hivemall @ Apache BigData '17, Miami
Apache Hivemall @ Apache BigData '17, Miami
Makoto Yui
機械学習のデータ並列処理@第7回BDI研究会
機械学習のデータ並列処理@第7回BDI研究会
Makoto Yui
Podling Hivemall in the Apache Incubator
Podling Hivemall in the Apache Incubator
Makoto Yui
Dots20161029 myui
Dots20161029 myui
Makoto Yui
Hadoopsummit16 myui
Hadoopsummit16 myui
Makoto Yui
HadoopCon'16, Taipei @myui
HadoopCon'16, Taipei @myui
Makoto Yui
3rd Hivemall meetup
3rd Hivemall meetup
Makoto Yui
Recommendation 101 using Hivemall
Recommendation 101 using Hivemall
Makoto Yui
Hivemall dbtechshowcase 20160713 #dbts2016
Hivemall dbtechshowcase 20160713 #dbts2016
Makoto Yui
Introduction to Hivemall
Introduction to Hivemall
Makoto Yui
Mehr von Makoto Yui
(20)
Apache Hivemall and my OSS experience
Apache Hivemall and my OSS experience
Introduction to Apache Hivemall v0.5.2 and v0.6
Introduction to Apache Hivemall v0.5.2 and v0.6
Introduction to Apache Hivemall v0.5.0
Introduction to Apache Hivemall v0.5.0
Idea behind Apache Hivemall
Idea behind Apache Hivemall
Introduction to Apache Hivemall v0.5.0
Introduction to Apache Hivemall v0.5.0
What's new in Hivemall v0.5.0
What's new in Hivemall v0.5.0
What's new in Apache Hivemall v0.5.0
What's new in Apache Hivemall v0.5.0
Revisiting b+-trees
Revisiting b+-trees
Incubating Apache Hivemall
Incubating Apache Hivemall
Hivemall meets Digdag @Hackertackle 2018-02-17
Hivemall meets Digdag @Hackertackle 2018-02-17
Apache Hivemall @ Apache BigData '17, Miami
Apache Hivemall @ Apache BigData '17, Miami
機械学習のデータ並列処理@第7回BDI研究会
機械学習のデータ並列処理@第7回BDI研究会
Podling Hivemall in the Apache Incubator
Podling Hivemall in the Apache Incubator
Dots20161029 myui
Dots20161029 myui
Hadoopsummit16 myui
Hadoopsummit16 myui
HadoopCon'16, Taipei @myui
HadoopCon'16, Taipei @myui
3rd Hivemall meetup
3rd Hivemall meetup
Recommendation 101 using Hivemall
Recommendation 101 using Hivemall
Hivemall dbtechshowcase 20160713 #dbts2016
Hivemall dbtechshowcase 20160713 #dbts2016
Introduction to Hivemall
Introduction to Hivemall
ロックフリーGCLOCKページ置換アルゴリズム
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