写真1●会場の様子。テーブルの上には中国茶の入った白いカップが見える。中国式なのでお茶の葉が直接カップに入っている。葉っぱを食べずにお茶をいただくには少々コツが必要
写真1●会場の様子。テーブルの上には中国茶の入った白いカップが見える。中国式なのでお茶の葉が直接カップに入っている。葉っぱを食べずにお茶をいただくには少々コツが必要
[画像のクリックで拡大表示]
写真2●当日配布された論文集
写真2●当日配布された論文集
[画像のクリックで拡大表示]
写真3●記念品の万年筆。もちろん中国製で,レトロな感じがよい味を出していた。ブランドは「英雄」。その昔日本でも「300 円の万年筆」で一世を風靡したものである。本品は本格的な吸入式で,結構使えそうな感じがした
写真3●記念品の万年筆。もちろん中国製で,レトロな感じがよい味を出していた。ブランドは「英雄」。その昔日本でも「300 円の万年筆」で一世を風靡したものである。本品は本格的な吸入式で,結構使えそうな感じがした
[画像のクリックで拡大表示]

 「第4回 北東アジアOSS推進フォーラム」で,私,SRAOSSの石井達夫は,PostgreSQLの検証結果を報告した。ソウルで開催された第3回にも参加しており,今回で北東アジアOSS推進フォーラムへの参加は2回目だ。

 中国は北京に3度ほど行っているが,天津は初めて。日本からの直行便は少ないので,一旦北京に入ってから車で天津に向かう。これが3時間位かかる。更に今回会場になったホテルはかなり郊外にあるところなので,ほとんどホテルに缶詰め状態ですごすことになったが,その分仕事に集中できたと言えるかもしれない。できれば次回からは北京や上海のように,直行便があるところで開催してくれると助かるのだが...

北東アジアOSS推進フォーラムの組織体制

 北東アジアOSS推進フォーラムの組織はワーキンググループ制になっている。筆者が参加したのはワーキンググループ1(WG1)で,Linuxサーバー,デスクトップ,セキュリティなどに関する課題を議論する場になっている。WG1では,5月13日に日本,中国,韓国から現在までの活動の報告,そして今後の方向性が議論された。

WG1での議論

 筆者は,PostgreSQLをDBT-3でテストした結果を報告した。DBT-3はOSDLで開発されたPostgreSQL用の負荷テストツールで,主にDSS(Decision SupportSystem)を想定した,複雑で重いSELECT問い合わせが評価対象になっている。既に過去の記事でPostgreSQL 8.1の著しい性能改善を報告したが,DBT-3を使ったテストでも同様の結果が見られた。

 次に報告したのは,PGClusterpgpoolSlony-I(いずれも筆者がITproで連載中のPostgreSQLウォッチで紹介している)のベンチマーク結果である。これらは実装方法は異なるものの,PostgreSQLに欠けているレプリケーション機能,負荷分散機能などを追加するものであり,PostgreSQLの適用範囲を広げることを目的にしている点は共通している。そこで,それぞれのソフトを利用したときの性能向上(あるいは劣化)を評価するのが性能測定の目的である。

 レプリケーションでは,更新の際に複数のDBサーバーに書き込みが発生するため,一般に単独のPostgreSQLよりも性能が低下する。一方検索問い合わせの際に負荷分散が使用できるソフト(PGClusterとpgpool)では,単独のPostgreSQLよりも性能が向上する。現実の業務では更新と検索が混在した問い合わせが使用される。そこでここでは,検索負荷と更新負荷の比率を10:0から0:10まで10段階に変化させたトランザクションを用意し,pgbenchを使って負荷をかけるテストを実行した。

 その結果,負荷分散機能があるPGClusterとpgpoolでは,純粋な検索問い合わせの際にサーバー台数にほぼ比例した性能向上が見られた。そして更新負荷が増えていくにしたがい性能が低下していく。PGClusterはその傾向が最も著しく,更新問い合わせが10%でも混じると単独のPostgreSQLよりも性能が低くなり,更新負荷100%では1/5程度に性能が低下した。pgpoolでは検索/更新が半々位まではpgpoolの方が単独のPostgreSQL よりも速く,更新負荷100% では65%程度に性能が低下した。Slony-Iが最も性能低下が少なく,更新負荷100%でも75%程度にとどまった。ただし,Slony-I は非同期式のレプリケーションであり,DBサーバーの間でレプリケーションタイミングのずれが発生することを考慮しておく必要があるだろう。また,負荷分散機能がないので,検索中心の負荷の場合でも性能向上は望めない。

 なお,言うまでもないが,この数値はどのような問い合わせを使うかで大幅に変化する。あくまで今回の試験で得られた結果であるということをご理解いただきたい。

PostgreSQL 8.1は8 CPUシステムでもスケールする

 その他PostgreSQL関連では,ユニアデックスの高橋氏から12個のCPUを搭載した大型のLinuxサーバーでPostgreSQL 8.1をベンチマークした結果が報告された。実際にテストに使用されたのはDBT-1という,これもOSDLで開発されたWeb上のショッピングサイトを想定したOLTP(On Line Transaction Processing)タイプの負荷をかけるツールである。その結果,CPU数が8個まではほぼCPU数に比例した性能向上が見られたことが報告された。PostgreSQL 8.0までは2 CPUまでしか実質的にスケールしなかったことを考えると,PostgreSQL 8.1ではスケーラビリティの点で目を見張る改善があったと言えよう。

 これらの詳細なベンチマーク結果は,IPAが5月に公開した「iPedia」に掲載されている。

14日の全体会議

 14日は全体会議があり,250名ほどの出席者があった(写真1,2,3)。午前中は各ワーキンググループからの議論の結果の報告があり,その後各国でOSSに更新した開発者の表彰式があった。日本からもRubyのまつもとゆきひろ氏をはじめ,数名の方が表彰を受けていた。

 午後はビジネス,技術,OSSコミュニティなどに関して各国から発表があった。筆者は「OSS Ecosytem」のセッションでの日本側の発表を担当した。「OSSEcosystem」は最近広まり始めたキーワードで,OSSの開発コミュニティに対してユーザーや企業が様々な援助や貢献を行い,OSSの継続的な発展を目指すという考え方である。このセッションの中で,筆者は「Collaborating with OSScommunities」というタイトルで,PostgreSQLの開発コミュニティ,日本のユーザー・コミュニティ,企業からのコミュニティへの貢献とフィードバックについて報告した。