リリースされたばかりのPostgreSQL 8.1は，巷ではその高速性が話題になって いる。今回本格的なテストマシンを借りることができたので，PostgreSQL 8.0 に比べてどの程度高速化されたのか検証してみたい。
検証用に64ビット機を使用
検証に使ったハードウエアは Sun Microsystems社製の「Sun Fire V40z」とい う機種。CPUはAMDのOpteron，クロック2.2GHzで動作させているものを4個搭載 しているマルチCPUシステムだ(デュアル・コアではない)。メモリーは8GBを搭載，ハー ドディスクはUltra320のSCSIである。OpteronはPostgreSQLとの相性がよいと いう噂もあるので検証が楽しみだ。
使用したOSは，Miracle Linux 4.0の64ビット版。カーネルのバージョンは 2.6.9である。
PostgreSQL 8.1と8.0をpgbenchで比較
検証に使用したPostgreSQLのバージョンは8.1.0と8.0.4である。ベンチマーク データの作成およびワークロードの生成には8.1に付属するpgbenchを使用し， PostgreSQLとpgbenchは同一マシン上で動作させた。
PostgreSQLはソースからコンパイルした。コンパイラはMiracle Linuxに付属 するgcc 3.4.3を使用，リンクされたpostgresは，以下のように64bit版のバイ ナリとして作成されている。
$ file postgres
postgres: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped
initdbのオプションは--no-localeと- E EUC_JPを指定した。
8.1のピーク検索性能は8.0の2倍近い
pgbenchにより10万件のテーブルを生成し，pgbench -S オプションを利用して インデックス経由で行を1件検索する単純な検索トランザクションを実行させ， 1秒あたりのトランザクション実行回数，すなわちTPS(=transaction per second)を性能の指標にした。測定ポイントは，同時接続数で 1,2,4,8,16,32,64,128,256,512とした。
postgresql.confには以下の修正を行っている。
max_connections=1000
shared_buffers=100000
これは8.1と8.0で共通の設定だ。
結果を図1に示す。縦軸がTPSで，上に行くほど性能が高い。横軸は同 時接続数であり，右に行くほど負荷が高いと考えてよい。
ご覧のように，すべての同時接続数でPostgreSQL 8.1が8.0を上回る性能を発 揮しており，特に同時接続数8のあたりでTPS値で23000を超えるパフォーマン スを示している。これは8.0のじつに1.9倍の性能だ。この数字はたいしたもの で，筆者の記憶ではpgbench -S で20000を超えるTPSは見たことがないので， ちょっと驚いてしまった。
また，8.0は同時接続数が8をピークに，あとはどんどん性能が落ちているのに 対し，8.1は同時接続数が128を超えてもほとんど性能の劣化がなく，非常に負 荷に強いことが分かる。
このように性能的に大差が付いた理由は，PostgreSQL 8.1でバッファの競合に よるボトルネックが解消されたことによると考えられる(詳細は本連載第16回 「PostgreSQLのバッファ・マネージャの改良」をご覧いただきたい)。
ベンチマーク実行中にtopコマンドでCPU使用率やload averageを観察してみる と，8.1ではCPU使用率が50%ほどであるのに対し，8.0は最大でも42%くらいにしか ならなかった。にもかかわらずload averageでは8.1が4から5なのに対し，8.0 は16から18と高い数値を示していた。これは，8.0ではロック待ちのために4つ もあるCPUを有効に使えず，効率的に処理できていないことによるものと考え られる。
更新性能でも大差
次に，pgbench -Nコマンドで更新処理を交えた処理でベンチマークを行ってみ た。この場合，10万件のテーブルに対し，更新，検索を行い，最後にログテー ブルに行を挿入するという一連の処理が一つのトランザクションになっている。
postgresql.confには先の設定に加え，以下を追加した(8.1, 8.0共通)
deadlock_timeout=10000
commit_delay=10
checkpoint_segments=16
wal_buffers=16
wal_sync_method=fdatasync
結果を図2に示す。こちらも8.1の方がかなり性能がよく，特に同時接 続数8や384のポイントでは，8.0から2倍ほども8.1が性能がよい結果となった。
バッチ処理性能
以上は同時接続数を大きくして負荷をかけた状態の性能検証だったが，単純な バッチ処理ではどうだろうか。
pgbenchでは，件数を指定してCOPYでデータをロード，インデックスを作成， VACUUMをかけるという一連の処理を行わせることができる。今回は100万件分 の処理を行ってみた。
結果を図3に示す。8.0で20秒ほどかかった処理が，8.1では15秒ほど で完了し，8.1の方が33%ほど速かった。これは，8.1でCOPY処理の性能が改善 されたことも大きいようだ。
シングルCPUシステムでの性能
最後に，手元のノートPC(Let's note CF-T2)を使って1 CPUシステムでの性能 を検証してみた。4 CPU/Opteronで劇的な性能向上を見せたPostgreSQL 8.1は， 「普通のマシン」でもよいパフォーマンスを示すかどうか確認するためである。
図1と同じベンチマーク・テストを実施した。CPUはPentium M 1.1GMHz，メモリーは768MB実装している。OSはVine Linux 3.2， カーネルのバージョンは2.4.31だ。postgresql.confは以下の設定を行った。
max_connections=1000
shared_buffers=10000
結果を図4に示す。
Sun Fireほど劇的ではないが，20-50%程度の性能改善が見られた。
データロードも計測した。図3と基本的に同じテストだが，ロードするデータ件数は1/10の10万件とした。図5のような結果となり，8.1が8.0 よりも64%高速だった。こちらはむしろSun Fireよりも改善度合いが著しい。
まとめ
PostgreSQL 8.1は，検索性能，更新性能の両面でPostgreSQL 8.0に比べ，大き な改善が見られる。性能の改善度合いはマルチCPUのマシンで特に著しく，場 合によっては2倍近い性能の向上があったが，シングルCPUのシステムでも 20-64% の性能改善があり，PostgreSQL 8.1は多様な環境で8.0よりも性能が向 上していると言ってよいだろう。今回の検証では「PostgreSQL 8.1は速い」と いう噂が裏付けられたことになる。
なお，PostgreSQL 8.1では，Opteron向けの低レベルのアセンブラコードが改 良されており，その成果が今回のベンチマークテストにも反映されている可能 性があるが，そこまでは検証できなかったことをお断りしておく。
マイナーバージョンアップ
従来のバージョンに比べ，著しく性能が向上したPostgreSQL 8.1だが，気にな るのは安定性である。もちろん今回の検証中に不安定になったり，不審な挙動 を見せることはなかったが，それにしても実務で使うにはもう少し枯れてから にしたいところだ。
そう思っていたところ，8.1のマイナーバージョンアップが近々ありそうな情勢に なった。本稿がアップされるころにはPostgreSQL 8.1.1がリリースされているか も知れない。8.1の安定を待って実務に導入を考えていたユーザーには朗報とな ろう。
最後になるが，実験用のハードウエアとソフトウエアを提供してくださったサ ン・マイクロシステムズとミラクル・リナックスの両社に感謝する。
■著者紹介
石井達夫（いしい・たつお）氏
国際化の分野を中心にPostgreSQLの開発に参加。一方，本業でもPostgreSQL関連のプロダクトやサービスの企画・開発を統括し，PostgreSQLを使ったビジネスの可能性を追求している。著書に『PostgreSQL完全攻略ガイド』（技術評論社），『PHPxPostgreSQLで作る最強WWWシステム』（技術評論社），『PostgreSQL構築・運用ガイド』（日経BP，共著）などがある。日本PostgreSQLユーザ会会員。
