TOP>企業情報>コラム>技術情報>PGEConsのドキュメントからPostgreSQLの「今」を知る! Vol.1

PGEConsのドキュメントからPostgreSQLの「今」を知る! Vol.1

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

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

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

初めて実施された更新系の性能検証


更新系検証ではPostgreSQLの更新系スケーラビリティとWALのロック競合の改善による効果を確認するため、コア数を15、30、45、60に、またセッション数を1から最大384まで変化させて、PostgreSQL 9.3と9.4で性能比較が行われました。アプリケーションは参照系と同じpgbenchが利用されています。

9.3では15コア192セッションの環境下でのTPSが34,000と最も高く、コア数の増加に伴い性能が低下する結果となりました。9.4でも15コアの環境が全般的に性能が良く、コア数の増加に伴い性能が低下するという傾向も9.3と同じでした。ただし、最大TPSは15コア320セッションの41,000で、9.3と比べて1.2倍のトランザクション数を処理できることが確認されています。コア数を増やしても性能が伸びない要因はいくつか考えられますが、CPUやディスクI/Oがボトルネックではないことはsarコマンドによるシステム稼働情報から把握できており、コア数と連動して増加したPostgreSQL内部のロック競合が一因だと推測されます。参照系処理では64CPUまでスケールする仕組みが9.2で実装されていますが、更新系処理は16コア程度までの性能向上に留まることがこれまで他の検証でも報告されており、次期バージョン以降での仕組みの実装を期待したいところです。

また、9.3と9.4で15コアの測定結果を比較してみると、図3にあるように192セッションまでは9.3のほうが性能が高い傾向にあるものの、192セッション以上になると9.3では性能が低下するのに対して9.4では320セッションまで性能が向上することが確認できています。また、384セッションで9.3と9.4の値を比較すると9.4が9.3の1.7倍の性能を発揮する結果となっています。

図3:9.3、9.4の更新性能比較

図3:9.3、9.4の更新性能比較

そこで、性能WGではロック競合の情報がログ出力されるようにPostgreSQLのソースコードを改修しました。図4は改修したバイナリを使用して9.3、9.4で処理中のPostgreSQLのロック競合回数を計測した結果ですが、WAL書き込みのロック競合を示すWALInsertLockの出力が9.3に比べて9.4のほうが低く抑えられていることが分かります。

図4:9.3、9.4のPostgreSQL内部のロック競合回数の比較

図4:9.3、9.4のPostgreSQL内部のロック競合回数の比較

また、弊社アシストでは、取り扱い製品である「Postgres Plus Enterprise Edition」(以下、PPEE)を利用して個別に検証を実施していますのでその結果もご紹介します。PPEEはPostgreSQLをエンジンとし、パフォーマンス、セキュリティ、GUIツールなどPostgreSQLに未実装のエンタープライズ向け機能を補完したRDBMSです。機能の1つとして待機イベントと呼ばれる仕組みが実装されており、これにより内部のどの処理で待機状態となっているかを確認することができます。待機イベントは、Oracle Databaseでは性能障害のボトルネックをピンポイントで特定する手段として広く利用されていますが、PostgreSQLでは同様の機能は実装されていません。そこで今回は、PPEEの待機イベントを利用してWALのロック競合の改善効果を確認しています。

弊社の検証では、PPEE 9.3と9.4の環境下で同一のOLTP処理を実行した際の性能差異を確認しました。図5は同時接続750セッションと1,000セッションの秒間トランザクションの平均値を表したグラフで、9.3では1,000セッションで性能が低下してしまいましたが、9.4ではセッション増加に伴い性能も向上することを確認しています。

図5:9.3、9.4における平均TPSの比較

図5:9.3、9.4における平均TPSの比較

図6はCPU使用率の推移と待機イベントの結果です。9.3ではユーザCPUが100%になるタイミングがあり、待機イベントをみると2番目に「wal insert lock acquire」というイベントが発生していました。このイベントがWALバッファの書き込みを待機していることを示しており、WALバッファのロック待ちが発生したことにより性能が低下したと判断できます。一方、9.4ではCPUの使用状況も安定し「wal insert lock acquire」イベントも発生していません。これは、上述の性能WGによるPostgreSQLのロック競合回数の計測結果と一致しており、同一セッション数で9.4のほうが高い性能を発揮するのはWALのロック競合改善の効果と言えます。性能障害のボトルネックを特定する場合、PostgreSQLでは今回のようにソースを改修すれば必要な情報を収集することも可能ですが、実システムでの採用は容易ではありません。一方、PPEEでは標準機能として提供されているため、簡単に利用することができます。PostgreSQLの採用を検討する際、PostgreSQLの機能をすべて保有し、さらに商用RDBMSと同等の運用レベルが確保できるPPEEを候補の1つに含めていただけたらと思います。

図6:CPU使用率と待機イベントの比較

図6:CPU使用率と待機イベントの比較

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

仮想技術「KVM」環境での性能影響度


2014年度は高性能サーバでの検証に加え、仮想環境での基本検証も実施しています。I/O性能が求められるデータベースは、これまで物理サーバを占有する構成が一般的でしたが、CPUのマルチコア化とメモリの大容量化、高性能化によって、システムに応じて仮想化の採用が増えています。そのような市場の状況を背景に仮想化によるオーバヘッドが処理性能に与える影響を測定しました。仮想化技術は「KVM」を利用し、物理、仮想サーバともにCPUコア数を10、メモリサイズを96GBに統一した環境下で前述した定点観測と同じ参照および更新処理を実施しています。

参照系検証では、図7にあるように物理サーバで最も性能が高くなる24セッションまではセッション数の増加に伴って仮想サーバとの性能差が拡大し、最大約10%の差が確認されました。尚、24セッションを超えると性能差は縮小傾向となりました。定点観測と同様にThinkTimeを設定しない状態での検証だったため、最も性能が高くなるセッション数は物理サーバではCPUコア数と同じ24セッションとなりました。一方、仮想サーバでは48セッションが最も性能が高く、物理サーバと比較して性能がピークとなるセッション数が2倍という結果が確認されました。ただし、CPU使用率をみると、物理サーバでは24セッションでCPUを100%使い切るのに対して、仮想サーバでは48セッションとなっており、これは仮想化によるオーバヘッドによってクライアントからの処理要求がCPUに遅延して届くためと推測されます。

図7:物理サーバと仮想サーバの参照性能比較

図7:物理サーバと仮想サーバの参照性能比較

更新系検証は参照系とは異なり、仮想サーバの場合、図8にあるようにセッション数の増加に連動して性能が低下する傾向となり、ピーク時の物理サーバとの性能差は40%という結果となりました。これは、セッション数の増加に連動してストレージへの書き込みI/Oが増え、リソース競合によって低下の度合いが大きくなるためと考えられます。また、sarコマンドによるCPU使用状況をみると、仮想サーバではセッション数の増加に伴いstealの値が大きくなり、userの値も物理サーバに比べて小さいことが確認されました。stealはゲストOSがリソース要求を行ったにもかかわらずCPUリソースを割り当てられなかった時間の割合を示しており、物理サーバに比べてCPUが有効に利用できていないことが分かります。

図8:物理サーバと仮想サーバの更新性能比較

図8:物理サーバと仮想サーバの更新性能比較

更新系検証ではもう1つの条件として、同じコア数とメモリを割り当てた仮想サーバを同一の物理サーバ上に2台用意し、更新処理をそれぞれのサーバに対して同時実行した場合に仮想サーバが互いに与える影響度を仮想サーバ単体と比較しました。2台の仮想サーバに対する更新処理の同時実行では性能差異がなかったものの、仮想サーバ単体と比較すると図9にあるように7%程度の性能低下が見られました。仮想化技術の特性上、仮想サーバ間で相互に影響を与えることはなく、また、仮想サーバ単体に比べて処理性能が低くなったことは想定内の結果と言えます。

図9:仮想サーバ単体と仮想サーバ2台の同時処理実行の更新性能比較

図9:仮想サーバ単体と仮想サーバ2台の同時処理実行の更新性能比較

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

話題のコンテナ型仮想技術「Docker」での性能影響度


近年「Docker」と呼ばれる技術が注目されています。Dockerは仮想環境にOSを含まないコンテナ型アーキテクチャを採用しており、アプリケーションの実行に必要なミドルウェアやライブラリを1つのコンテナにまとめて管理します。そのためアプリケーションの実行環境を簡単に複製したり、リソースを節約できるといったメリットがあります。Docker上でデータベースを稼働した際の性能面の影響度は、情報が少ないこともあり、2014年度の検証候補に挙がりました。

2014年度の検証では、Dockerを利用した4パターンのコンテナ環境(ファイルシステムの配置場所(ホスト直接またはコンテナ内)、ネットワークの種別(ホスト直接または仮想ネットワーク)を条件としています)に、非コンテナ環境を加えた合計5パターンにて定点観測で利用した参照、更新処理を実行し、性能傾向を確認しています。

参照系検証では処理対象のデータがすべてメモリ上に乗りきる状態としており、この条件の下では図10にあるようにすべてのパターンで同等の性能を発揮することが確認されました。つまり、Dockerによる仮想化の影響は最小限と言えます。

図10:Docker環境下での参照性能比較

図10:Docker環境下での参照性能比較

更新系検証では、図11にあるようにファイルシステムがホスト直接のケース(1および2)とコンテナ内のファイルシステムを利用するケース※1(3および4)で性能差異が発生しました。ホスト直接のケースでは、非コンテナ環境とほぼ同等の性能が確認されています。これはコンテナ内のファイルシステムの実装に利用されるLVM thin provisioningのオーバヘッドによるものと推測されます。sarコマンドによるCPU使用状況をみるとケースごとにUserの使用率の違いが見られるため、DeviceMapper経由の書き込みまたは他の部分でロック待ちの発生が起因していると推測されます。

図11:Docker環境下での更新性能比較

図11:Docker環境下での更新性能比較

※1 グラフ縦軸の名称はそれぞれ以下の環境を示しています。

図12:図11のグラフ縦軸の名称

図12:図11のグラフ縦軸の名称

Dockerコンテナはその手軽さから、一度停止し破棄を行うとコンテナ内に保存されたデータも破棄されてしまうという特徴があります。そのため本番のデータベースシステムでコンテナ内にデータベースファイルを配置することは現実的とは言えず、実際にはホストのファイルシステムの利用が前提となるため、今回の検証結果が実用上問題になることは少ないと考えられます。PostgreSQLの開発やテスト環境でのDockerの利用は十分実用に耐えうるレベルであると言えます。

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

性能WGでは、毎年最新のPostgreSQLモジュールで各種検証を実施し、数値情報の蓄積を行っています。定点観測と呼ばれる参照系、更新系の基本性能の把握に加え、2014年度はKVMやDocker上のPostgreSQLの性能把握という新たなテーマにも取り組みました。これらのテーマはPGEConsのセミナーに参加されたお客様のリクエストをもとに採用されており、市場のニーズに応える内容となっています。ドキュメントには、検証結果だけでなく検証で使用したスクリプトやDockerの起動手順など詳細な情報が掲載されていますので、PostgreSQLの評価や採用を進める際にはぜひ参考にしてください。

PostgreSQLエンタープライズ・コンソーシアム 2014年度活動報告
https://www.pgecons.org/download/works_2014/

次回は、災害対策とセキュリティ課題をテーマとした運用設計ワーキンググループの成果ドキュメントをご紹介します。お楽しみに。

  • Postgres Plus は、EDB Postgres の旧製品名です。


執筆者紹介

高瀬 洋子(Youko Takase)

株式会社アシスト データベース技術本部

アシスト入社後、Oracle Databaseのサポート業務を経て、2009年よりPostgreSQL、EDB Postgresのサービス立ち上げに参画。「PostgreSQLなら高瀬に聞こう」と社内外から言ってもらえる存在となることを目標に日々活動。2014年4月よりイギリスに拠点を移し、PostgreSQL、EDB Postgresの啓蒙活動と顧客対応の後方支援を担当。

高瀬の紹介記事はこちら

連載記事一覧

関連製品/サービス


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る