話題の仮想環境でも性能測定!性能ワーキンググループの活動成果 (1/3):EnterpriseZine(エンタープライズジン)
Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

話題の仮想環境でも性能測定!性能ワーキンググループの活動成果

2015/08/07 06:00

 エンタープライズ領域でのPostgreSQLの普及促進を目指して設立されたPostgreSQLエンタープライズ・コンソーシアム(略称:PGECons)。本連載では、3年目となった2014年度の活動を通じて新たに提示された性能、移行、設計運用に関する数百ページにわたるドキュメントを項目ごとに読みやすく要約してご紹介していきます。

3年を超えたPostgreSQLエンタープライズ・コンソーシアムの活動

 「PostgreSQLエンタープライズ・コンソーシアム(以下、PGECons)」は、エンタープライズ領域でのPostgreSQLの普及促進を目的に2012年4月に発起人企業10社で設立した団体です。主にPostgreSQL関連サービスを提供する企業が中心となって活動していますが、正会員、一般会員へのユーザ企業の参画も年々増えており、来る9月11日にはPostgreSQLの活用事例セミナーの開催も決定しています。セミナー詳細については本記事の一番下もご参照ください。

 PGEConsの主な活動基盤である技術部会では、オープンソースソフトウェア(OSS)のRDBMSであるPostgreSQLを企業で安心して活用するために必要な情報を提供すべく、複数のワーキンググループに分かれて検証や情報集約を行い、その活動成果を毎年ドキュメントとして公開、またセミナーで発表しています。2012年設立当時、参画企業メンバーが日々感じていたPostgreSQLの課題やユーザの要望をそれぞれ持ち寄り、どのような情報をまとめるべきかを話し合った結果、初年度はPostgreSQLの性能を検証する「性能ワーキンググループ(性能WG)」とデータベース移行手法を検討したり考慮点をまとめる「移行ワーキンググループ(移行WG)」が立ち上がりました。翌年の2013年からは「設計運用ワーキンググループ(設計運用WG)」が新たに設けられ、可用性、バックアップ、監視の観点からPostgreSQLで構築可能なシステム構成の動作検証が行われました。

 3年目となった2014年度も前年度と同じ3つのワーキンググループでの活動が継続され、成果ドキュメントはこれまでと同じく、合計数百ページにものぼる品質の高いものに仕上がっています。本連載では3回にわたり、ドキュメントの内容を項目ごとに分かりやすく要約し、ドキュメント該当ページの案内と弊社視点の考察を入れた形でご紹介していきます。成果ドキュメントを参照する際の一助になれば幸いです。

 今回ご紹介する性能WGは、「大規模な業務システムでのPostgreSQLの適用範囲を明確化する」ことを目標に、中でも「性能」に焦点を絞り、これまでマルチCPUコア環境でのスケールアップや負荷分散クラスタでのスケールアウト、また大規模データを扱う際に有効なパーティショニングの有効性などの検証を行ってきました。

 2014年度は毎年継続して実施しているPostgreSQL最新バージョン(2014年度は9.4)での定点観測に加え、更新処理の性能検証が初めて実施されました。これは、変更履歴データが格納されるWALに関して、データ圧縮によるファイル出力量の軽減と書き込みにおけるロック競合の改善による並列書き込み性能の向上という2つの機能変更が9.4で実装されており、その効果を把握するためです。また、これまでの高性能サーバを利用した検証に加え、近年、データベースサーバとしての利用が拡大している仮想環境での検証もポイントです。次から検証結果をそれぞれ見ていきましょう。

最新バージョン 9.4の性能は?

 定点観測として毎年実施している参照系検証では、サーバのCPUコア数を60で固定し、セッション数を1から128まで変化させて、PostgreSQL 9.3と9.4の性能比較が行われました。尚、アプリケーションはPostgreSQL付属のpgbenchと呼ばれるベンチマークツールを利用し、ある1つのテーブルから10,000行のデータをランダムに取得する処理を実行しています。

 検証を実施した時点はPostgreSQL 9.4正式版がリリースされる前だったため、検証ではリリース候補版である9.4 RC1を利用しました。図1のグラフは横軸が同時接続数、縦軸は1秒間あたりのトランザクション数(TPS)を示しており、9.4 RC1のほうが若干TPSの値が低い結果となりましたが、大きな性能差はなく、いずれもセッション数の増加に伴い80セッション程度まで性能が向上することが確認されています。

 今回の検証シナリオではセッションごとの処理間隔(以下、ThinkTime)を設定していないため、TPSが最大になるセッション数はCPUコア数と等しくなると想定していましたが、CPUコア数の60を超えて80セッションまでTPSが向上する結果となりました。CPU使用率をみると60セッションでは80%程度の使用に留まっており、一方、80セッションでは98%とほぼ使い切った状態でした。CPUに適切に負荷がかかるSQL処理であればCPUコア数と等しいセッション数で最大TPSとなると考えられますが、実システムに則してThinkTimeを設定した場合、より多くのセッションからの処理を受け付けることができます。

図1:9.3、9.4の参照性能比較
図1:9.3、9.4の参照性能比較

 ※参照系検証の詳細は「2014年度WG1活動報告」p9-p15をご参照ください。→ https://www.pgecons.org/downloads/89

 9.3で実装された新機能に「ページチェックサム」があります。これは商用RDBMSでは従来から実装されており、テーブルやインデックスのデータ破損を検知する仕組みです。PostgreSQLでは本機能はオプションとして実装されており、データベースクラスタ作成時に「-k」オプションをつけることで有効になります。今回、定点観測の位置づけで9.3と同様に9.4環境下でページチェックサムの設定有無による参照処理性能への影響度を確認しています。

 昨年度実施された9.3の検証では、同時セッション数が少ない場合はページチェックサムの設定有無による性能差異はなかったものの、セッション数の増加に伴いCPUの負荷が高くなるとページチェックサムのオーバヘッドが現れてくるという結果でした。一方、9.4では図2のグラフにあるように、ページチェックサムの設定有無や負荷の状況にかかわらず、それぞれ同程度の性能が確認できており、ページチェックサムが参照処理に与える影響はほぼないと言えます。更新処理への影響度は、今後の性能WGでの定点観測に期待したいところです。

 ドキュメントではページチェックサムの内部処理を効率よく行うためのコンパイルオプションが紹介されており、ソースコードを改修することでコンパイルオプションの有無による性能比較も実施しています。これはOSS製品ならではの検証と言えます。尚、このオプションはデフォルトで有効になっているため、一般にPostgreSQLを利用する上で意識する必要はありません。

図2:ページチェックサムの設定有無による参照性能比較
図2:ページチェックサムの設定有無による参照性能比較

 ※ページチェックサムの検証詳細は「2014年度WG1活動報告」p16-p18をご参照ください。→ https://www.pgecons.org/downloads/89

※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 高瀬 洋子(タカセ ヨウコ)

     株式会社アシスト データベース技術本部  アシスト入社後、Oracle Databaseのサポート業務を経て、2009年よりPostgreSQL、EDB Postgresのサービス立ち上げに参画。2017年4月にイギリスから日本へ拠点を戻し、海外イベントで得た情報などを活かしてEDB Postg...

バックナンバー

連載:PGEConsのドキュメントからPostgreSQLの「今」を知る!
All contents copyright © 2007-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5