PostgreSQLウォッチ第7回でも解説した
PostgreSQL 7.4対応で大幅性能向上
以前からpgpoolはPostgreSQL 7.4でも使うことはできたが,それはあくまでPostgreSQLの旧プロトコルへのフォールバック機能を使用しているに過ぎなかった。このため,PostgreSQL 7.4で採用された新しいプロトコルのメリットである効率の良さや新しい機能(例えばPREPARE/EXECUTEなど)を生かすことはできなかった。pgpool 2.0では,完全にPostgreSQL 7.4のプロトコルに対応し,こうした問題が解消された。
本来レプリケーションの必要のない検索系では,pgpoolによるオーバーヘッドが気になるところである。そこで今回もpgbenchを使って検索のみの性能測定を行ってみた。測定条件はすべて同じで,同時接続数10,各接続あたり1000トランザクションを実行している(表1および図1[拡大表示])。
表1●検索におけるpgpoolのオーバーヘッド
測定条件 | TPS値 | pgpoolなしの場合と比較した相対性能 | 前回の相対性能 |
---|---|---|---|
pgpoolなし | 4357.625059 | 100% | 100% |
pgpoolあり(レプリケーションなし) | 4330.290294 | 99.40% | 94.10% |
pgpoolあり(レプリケーションあり) | 4297.614996 | 98.60% | 87.60% |
pgpoolあり(レプリケーションあり,strictモード) | 4270.223136 | 98.00% | 81.50% |
| ||
|
このように,最悪でもオーバーヘッドは2%である。前回pgpool 1.0で計測したときは最悪20%近いオーバーヘッドがあったことと比べてみると,pgpool 2.0では大幅な性能向上が達成されたことが分かる。
次に更新系でのテストを行ってみた。前回と同じ条件で更新系のテストをした結果が図2[拡大表示]である。
pgpoolなしの場合とpgpoolありの場合を比較すると,最悪の場合(同時接続ユーザー数1)で60%,最良の場合(同時接続ユーザー数64)で93%,平均83%の性能が得られた(同時接続ユーザー数が128の場合むしろpgpoolありの方が良い性能を示しているが,これは測定誤差であろう)。前回pgpool 1.0で測定したときは最悪で48.5%,最良で81%,平均65.8%であったから,pgpool 2.0では更新時にもかなり性能が向上していることが確認された。
コネクション・プーリングの効果
pgpoolにはPostgreSQLへの接続をキャッシュする機能がある(というより,もともとそれが目的で開発されたソフトウエアである)。これにより,データベースへの接続オーバーヘッドを減らすことができる。前回この効果を確かめていなかったので,この点についても測定を行った。
測定条件は検索系のときとまったく同じである。ただし,pgbenchの引数に-Cを追加し,トランザクションを開始するたびにDBへ接続し直すようにした。
図3●コネクション・プーリングの効果 |
負荷分散の効果
pgpool 2.0の最大の目玉は負荷分散機能である。これは,以下の条件が揃ったときにSELECT文を2台のPostgreSQLに振り分けることにより,性能を向上させようというものである。
- プロトコルバージョンがV3であること。すなわちバックエンドがPostgreSQL 7.4以後であること
- SQL文が正確に行頭からSELECT(あるいはselect)で始まっていること
- SELECT文が明示的なトランザクション・ブロック内で実行されていないこと
更新を伴う関数を呼び出すような副作用のあるSELECT文を使用している場合は問題が起きる。負荷分散によってマスタかセカンダリのどちらかのデータベースだけが更新されてしまうからである。このような場合はpgpool.confの設定項目「load_balance_mode」をfalseにするか,SELECT文の行頭にスペースや/*NO LOAD BALANCE*/のようなコメントを挿入して負荷分散されないようする。
図4●負荷分散の効果 |
pgpoolの今後
pgpoolは負荷分散対応をしたことにより,ほぼ完成の域に近づいている。今後はpgpoolのダウンがシステム全体のダウンにつながらないような対策を目指したい。例えば,2つのpgpoolが相互に監視を行い,相手がダウンしたことを検出して自動的に生きている方に切り替わるような方法が考えられる。もちろんハードウエアの負荷分散装置や,UltraMonkeyを使っても目的は達成できるので,pgpool自体がこうしたフェールオーバ機能を独自に持った方がよいのかどうかは考慮の余地があるだろう。
もう一つ面白いpgpoolの使い方としては,pgpoolがPostgreSQLのproxyサーバーであることを利用してPostgreSQLの管理に役立てることである。Slony-Iというレプリケーションソフトが最近リリースされたが,Slony-Iの開発者はSlony-Iとpgpoolを併用し,Slony-Iのメインテナンスを行う際にpgpoolを停止させることによってWebアプリケーションとPostgreSQLを停止させることなく,WebアプリケーションからのSlony-IやPostgreSQLへのアクセスを禁止するような使い方をしているそうだ。
pgpoolがこうした使い方をされるとは筆者は思いもよらなかったが,一方でpgpoolの新しい使い方について大きなヒントを得たような思いがした。
今後もこうしたいろいろなアイデアを取り込み,pgpoolがPostgreSQLにとってさらに効率よく,かつ便利に使えるツールになることを目指していきたいと考えている。
■著者紹介
石井達夫(いしい・たつお)氏
国際化の分野を中心にPostgreSQLの開発に参加。一方,本業でもPostgreSQL関連のプロダクトやサービスの企画・開発を統括し,PostgreSQLを使ったビジネスの可能性を追求している。著書に『PostgreSQL完全攻略ガイド』(技術評論社),『PHPxPostgreSQLで作る最強WWWシステム』(技術評論社),『PostgreSQL構築・運用ガイド』(日経BP,共著)などがある。日本PostgreSQLユーザー会会員。