JPUG広報部ブログにOSCON2005で発表された「Explaining Explain」の日本語版ドラフトが公開されています。
EXPLAINとはPostgreSQLのコマンドで、クエリの実行プランや実際の実行時間を表示させる為に使います。SELECT min(val) FROM my_table; が何故遅いのか等、が解るツールです。クエリの最適化、PostgreSQLサーバの設定ファイル（postgresql.conf）のrandom_page_costの最適化などには欠かせないコマンドです。
非常に参考になります。もし読まれた事がない方はぜひどうぞ。
PostgreSQLのパフォーマンスはpostgresql.confに大きく影響されるので、速くなったかどうか判りづらい場合も多いです。しかし、8.1では確実に速くなっているようです。現在8.1はbeta1ですが少しだけ比較してみました。
詳しくはWikiのページを見ていただくとして以下の様にpgbenchで計測すると
./pgbench -v -h 192.168.100.204 -U yohgaki -c 20 -t 200
PostgreSQL 8.0.3
tps = 4683.835265 (excluding connections establishing) (Select only)
tps = 1032.798585 (excluding connections establishing) (Update 省略）
tps = 423.926137 (excluding connections establishing)
PostgreSQL 8.1beta1
tps = 5985.801678 (excluding connections establishing) （Select only)
tps = 1428.605103 (excluding connections establishing)（Update省略）
tps = 533.005286 (excluding connections establishing)
という感じの結果になりました。
postgresql.confの設定は多少チューニングした物を使っています。postgresql.confもWikiのページに添付してあります。
実はpthread版pgbenchの作成には別の目的もあります。オリジナル版pgbenchのコードを見ると分かるのですが、非同期クエリを使用しているので送信するクエリのカスタマイズが面倒です。pthread版pgbenchの別の目的、と言うより本来の目的、はpostmasterが書き出したログから自動的にクエリを収集し、再生するベンチマークを簡単に行いたいので作る、と言う事にあります。
今の所こんな感じで実装するつもりです。
postgresql.confのログ設定が
log_line_prefix = ‘%r’
log_statement = true
で出力されたログから自動的に各クライアントのクエリを出力し設定されたスレッド数（クライアント数）でベンチマーク出来るようにする予定です。
今のコードだとログの読み取りとクエリ保存を行えるようにして、各スレッドがクエリを実行するように変更すれば良いだけです。簡単なのでそのうち変更します。
（やはりバグを発見したので修正）
JPUG広報Blogに「pgbenchのpthread版が欲しい」と書いていましたが、先週末にPHP関西のセミナー講師を引き受けていたのでその移動時間中にテキトーに作ってみました。テキトーに作ったので勘違いしてバグを入れていました。今度はたぶん正しい結果になっていると思います。
サーバ環境
Athlon64 3200/3GB Memory/SATA2 HDD/Momonga Linux x86_64
PostgreSQL 8.0.3(64bit)（全てのSQL文をホスト/ポート付きで記録。他はほぼデフォルト。）
クライアント環境
AthlonXP 2500+/2GB Memory
pthread版pgbench
[yohgaki@dev pgbench]$ time ./pgbench -v -h 192.168.100.204 -U yohgaki -c 10 -t 100
starting vacuum…end.
starting full vacuum…end.
Warming up 15 seconds…
Start benchmarking…
End benchmarking….. (4.96586 seconds)
transaction type: TPC-B (sort of)
scaling factor: 10
number of clients: 10
number of transactions per client: 100
total number of transactions processed: 1000
tps = 235.404176 (excluding connections establishing)real 0m25.739s
user 0m0.214s
sys 0m0.313s
[yohgaki@dev pgbench]$
こんな感じです。
何だか遅くなってしまたのでコードをもう少し効率化してみました。
今度はオリジナル版よりは速くなりました。
pthread版pgbench
[yohgaki@dev pgbench]$ time ./pgbench -v -h 192.168.100.204 -U yohgaki -c 50 -t 10
starting vacuum…end.
starting full vacuum…end.
Warming up 0 seconds…
Start benchmarking…
End benchmarking….. (1.16363 seconds)
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 50
number of transactions per client: 10
total number of transactions processed: 500
tps = 429.689481 (excluding connections establishing)real 0m2.655s
user 0m0.047s
sys 0m0.088s
オリジナル版
[yohgaki@dev pgbench]$ time pgbench -v -h 192.168.100.204 -U yohgaki -c 50 -t 10
starting vacuum…end.
starting full vacuum…end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 50
number of transactions per client: 10
number of transactions actually processed: 500/500
tps = 337.674248 (including connections establishing)
tps = 379.093451 (excluding connections establishing)real 0m1.615s
user 0m0.043s
sys 0m0.210s
と、多少スレッド版の方が速いです。今度は繰り返し実行してみてもスレッド版の方が速い傾向は変わりませんでした(汗
ベンチマークを開始する前にウォーミングアップの時間を設定したかった事、クエリ実行間隔をランダムに設定したかった事もpthread版が欲しかった他の理由でした。そこで
-w ウォームアップ時間（秒）
-r ランダム遅延（マイクロ秒）
も設定できるようにしました。よくあることですがサーバに負荷をかけた直後は良い性能がでるためウォームアップ時間は設定できた方が便利です。
ウォームアップ時間を5秒に設定した場合
[yohgaki@dev pgbench]$ time ./pgbench -v -h 192.168.100.204 -U yohgaki -c 50 -t 10 -w 5
starting vacuum…end.
starting full vacuum…end.
Warming up 5 seconds…
Start benchmarking…
End benchmarking….. (1.48874 seconds)
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 50
number of transactions per client: 10
total number of transactions processed: 500
tps = 335.854481 (excluding connections establishing)real 0m6.671s
user 0m0.124s
sys 0m0.260s
とこの様な感じです。オリジナル版にウォームアップ時間オプションを追加して欲しいな、と書いておいたら石井さんが追加してくれるはず :)
ソースは
http://www.ohgaki.net/wiki/index.php?PostgreSQL%2Fppgbench
からダウンロードできます。変更するかもしれないので日付を入れておきました。日付が入っていないソースは古いソースです。もし古いソースをお持ちの場合、新しいソースを使ってください。古い物にはバグがあります。
どこでも状況は似ているとは思いますが、JPUGの活動を支えてくださるスタッフを募集中です。東京近郊の方は是非ご協力下さい。
メモ。JPUG広報用のブログ。IE等で見るとレイアウトが崩れたりしますが、そのうち修正される予定です。
pgpool 2.6の人柱を募集中とのことです。こういったものは広く告知した方がよいのでpgsql-jp MLのメッセージをそのまま貼り付けます。
石井です．
久々にpgpoolのバージョンアップをしようとしています．ついては，できたばかりのV2.6のアルファ版を，
http://www2b.biglobe.ne.jp/~caco/pgpool/tmp/pgpool-2.6.tar.gz
に置きましたので，人柱になっても良い，という方は是非ご協力をお願いします．
2.6の目玉は，SERIAL型への対応です．といっても，やっていることはごく単純で，INSERT文があったらそのテーブルに自動的にテーブルロックをかけるだけです．トランザクションの並列実行性は犠牲になりますが，SERIAL型の列がマスタとセカンダリで一致しなくなることは防げます．
ちなみに自動ロックの機能はSERIAL型を含まないテーブルにも働いてしまいます:-)回避方法はREADME.euc_jpをご覧下さい．
以下，2.5.2からの変更点のリストを付けておきます．
——————————————————————-
o pool_error etc.で，asprintfの後でfreeしていなかったのを修正．o main.cで，mallocのサイズが誤ってpool_config.num_init_children
* sizeof(pool_config.num_init_children)
になっていたのをpool_config.num_init_children * sizeof(pid_t)に修正．o parameter statusの値が一致していなくてもエラーにならないようにした(USとNZでレプリケーションしている例があった！)．
o pgpool stopで終了せず，一旦killされた後，pgpool -m f stopを受け付けなくなるバグを修正．
o 新しいディレクティブinsert_lockを追加．trueの場合，INSERT実行時に自動的にテーブルロックを行う．これにより，SERIAL型を含むテーブルの同期を取ることができる．なお，/*NO INSERT LOCK*/コメントを付けると，そのINSERT文のみテーブルロックを行わない．あるいはinsert_lockがfalseでも/*INSERT LOCK*/コメントを付けるとテーブルロックを行う．
o 2.5.2で追加された「strictモードであっても，SELECTだったらsecondaryの完了を待たない」仕様を取りやめ．代りに，/*NO STRICT*/コメントを追加．
o show pool_statusに新しい情報を追加．縮退やフェイルオーバ状況を分かりやすく表示するようにした．
server_status| master( on 5432) up secondary( on 5433) down| server status
——————————————————————-
—
Tatsuo Ishii
この練習問題は以前にある方の日記から知ったのですが、これが結構難しい。前に一度やってみたのです散々な結果だったので、またそのうちと思っていてもう一度やって見ましたが… まあ今回も飲酒試験でしたが前よりは酔ってなかった＆まえよりは時間をかけて回答したので少し凹みました。 前に試しにやってみた時の記憶は全く無かったので初めてと同じ状態とはいえ…
さすがに解答を見ても「何故?」と言う物はなく「そうでしたね…」という物ばかりでした。結構時間に余裕がある試験らしいので解答後に見直しをすれば合格するかも知れないレベルかも知れませんが、確実に合格するには勉強しないとならないですね。
この手の認定試験の効果に疑問符を付ける意見も多く見られますが、試験に合格する為に身に着けた知識は結構役立つと思います。例えば私の場合、MSCP試験を前の会社に在籍していた際に時間をみて受験し、Windows 3.1 ～ Windows2000 Serverまでは受験し合格しています。Windows2000 Professional/ServerのMSCP試験の為に身に付けた知識は、仕事で使うことはもうほとんど無いですが、WindowsServer、WindowsXPでも役立っています。WindowsのNETコマンドは覚えていて便利な事は多いです。普段使っているシステムやプログラムでも体系的に学ぶことは重要と思います。
PostgreSQL CE Goldのサンプル問題も無茶な問題では無いとは思います。しかし、この問題を解くための知識はマニュアルだけでは得られないような気がします。7.0以降のマニュアルは全てのページを読んでいないので、記憶もかなり曖昧、あくまで、気がするだけです。
PostgreSQL CE試験の知識も長い期間役立つはず、という事で素直に絶対合格!PostgreSQL CE認定試験〈Silver〉をアマゾンで購入しました。でもGold試験に役立つのかな?
この手の試験は割と良い成績である場合が多いのですが、今回は凹む結果だったのでちょっと悔しいですね。PostgreSQL 8.0 Gold試験はこっそり受験しよう。
# 確かMSCP試験を多数受験するきっかけもWindwos3.1の試験に1度目
# で合格しなかった事が原因だったような気がしますね。
# しかしこの試験、こっそり受験するには偽名が必要だったりして..
とりとめがなくなりつつありますが、これに合格しているのであれば自慢できると思います。この試験お勧めと思いますよ！
私が「まるごとPostgreSQL」(インプレス)に書いた記事がシンクイット(ThinkIT)から順次読めるようになります。
このサイトはコメントが送信できるようになっています。ツッコミなどありましたら是非お願いします。
下記の内容で「PostgreSQLセミナー2004@沖縄」が開催されます。
「PostgreSQLセミナー2004@沖縄」
主 催：琉球大学 日本PostgreSQLユーザ会 ＯＳＰＩ
日 時：2004年12月10日（金） 13:00〜17:30
会 場：琉球大学 工1-321
参加費：無料
申込み：
懇親会：スケジュール：
13:00〜13:50 「PostgreSQL 8.0の概要」
講演者：片岡 裕生（日本PostgreSQLユーザ会理事長）
概要：
本格的なリレーショナルデータベース管理システムであるPostgreSQLが、このたびバージョン8.0となって飛躍的な進化を遂げました。待ち望まれたWindowsサーバの登場やアーカイブログによるメディアリカバリ機能、Point InTime Recovery機能など、新バージョン8.0には魅力的な機能が満載です。この講演では、PostgreSQL 8.0の特徴と新機能を紹介します。14:00〜14:50 「多機能コネクションプールサーバpgpool」
講演者：石井 達夫（(株)株ＳＲＡ）
概要：
「PHP+PostgreSQLなどのWeb環境におけるDB利用を効率化，高可用化する多機能コネクションプールサーバpgpoolをご紹介します。pgpoolの概要、使い方、さらには性能評価にも触れます．」15:00〜15:50 「PGClusterの最新動向」
講演者：三谷 篤（日本PostgreSQLユーザ会理事／広島地区支部支部長）
概要：
PostgreSQLで負荷分散や高可用性システムを構築できるマルチマスタ同期レプリケーションシステムのPGClusterをご紹介します。公開版の基本機能に加え、次バージョンで予定している新機能の紹介と、システム構築例をご紹介します。また、PostgreSQL7.4対応の状況も併せてご報告します。16:00〜16:50 「Webアプリケーション構築におけるセキュリティーの基礎」
講演者：大垣 靖男（日本PostgreSQLユーザ会理事／四国支部支部長）
概要：
多くのWebアプリケーションはインターネットに公開される事が前提として開発されます。どのようなWebアプリケーションでも立派なネットワークアプリケーションであり、セキュリティーには十分な配慮が必要です。スクリプト系の言語やJava言語の様にメモリ管理が不必要なプログラミング言語を利用した場合でも発生するセキュリティー問題の基礎知識をご紹介します。17:00〜17:30 後援企業講演
「遂にスタート! PostgreSQL CE(技術者認定制度)の概要」
講演者：稲葉 香理（(株)ＳＲＡ、日本PostgreSQLユーザ会理事／事務局担当）
セミナーの講演資料(PDF)をJPUGのサイトにアップロードしました。講演名横の「資料」リンクからダウンロードできます。ご利用ください。
# ミニうどんつあー。時間は2時間のミニツアーでしたが6軒まわりました。
無事完了！
会場の席もいっぱいになるくらいの方にいらして頂きました。来年も同様の企画を行いたいと思っています。
# 今日はミニうんどつあーです。