データベース・システムにとって,バッファの管理を一手に引き受けるバッファ・マネージャは,ディスクI/O効率,ひいてはデータベース・システムのパフォーマンスを左右する重要な構成要素だ。PostgreSQL 8.0のバッファ・マネージャは,ARC(Adaptive Replacement Cache)というアルゴリズムを採用し,以前のバージョンに比べるとパフォーマンスが向上している。

 しかし,ARCは米IBMが特許を出願中であるため,特許が成立するとARCを使えなくなってしまう可能性がある。もちろん特許が成立するまではARCを使うことに何ら問題はないが,それでも早いうちに手を打つに越したことはない,ということでPostgeSQLの開発者はARCに代るアルゴリズムを採用すべく開発中である。新しいアルゴリズムは,まもなくリリースされると思われるPostgreSQL 8.0.2に搭載される予定だ。

2つある改良ポイント

 バッファ・マネージャの改良ポイントは2つある。一つは前述のようにARC特許を避けるために,同様の効果を持ちながら,ARCとは異なったアルゴリズムを使うことである。これについては「2Q」と呼ばれるアルゴリズムが採用されることになっている。

 今回はもう一つの改良点についてレポートする。こちらの方は,性能を向上させるための改良で,次期メジャー・バージョン8.1に搭載すべく既にCVSにコミットされており,しかも実際にパフォーマンス向上をもたらしている。そこで本稿ではその概要と,簡単なベンチマーク結果をお届けすることにする。

 なお,いつものことであるが,ここで触れる内容はあくまで開発途中のものであり,8.1がリリースされる際には異なったものになっている可能性があることをお断りしておく。

バッファ・マネージャ・ロックの排除

 バッファ・マネージャが管理するバッファは共有メモリー上にあり,すべてのユーザーからアクセスされる。そのため,きちんと排他制御する必要がある。このためのロックが「バッファ・マネージャ・ロック」である。簡単に言うと,バッファ全体を一度に一つのプロセスしかアクセスできないようにするものだ。

 バッファは頻繁にアクセスされるため,このロックがボトルネックになって性能が低下するという指摘が以前からあった。今回の改良では,バッファ・マネージャ・ロックを排除することに成功し,代りにもっと軽い「バッファ・マッピング・ロック」が採用された。バッファ・マッピング・ロックは共有ロックであるため,読み取り目的であれば,複数のプロセスが同時に保有できる。その分並列実行性が向上するわけだ。もちろんバッファの内容を変更するためには占有ロックが必要になるが,読み出しだけであれば以前と違って占有ロックが必要なくなっているので効率が向上している。

 また,再利用可能なバッファのリストの管理方法がLRU(Least Recently Used)から「clock sweep」アルゴリズムに変更された。これは,LRUでは排他的なバッファ・マネージャ・ロックを避けることができないからである。clock sweepアルゴリズムはLRUほど厳密にバッファの利用頻度を管理できないが,オーバーヘッドが少いこともあり,バッファ・マネージャ・ロックの排除と相まってトータルでの性能向上が期待できる。

 それでは早速バッファ・マネージャの改良による性能向上が実際にあるのかどうか検証してみよう。