TOP
＞
比較データ
＞ DBT-1をPostgreSQLに適用すると見えてくるもの
オープンソースソフトウェアの性能・信頼性評価手法
第６回：PostgreSQLは使えるのか？
〜 あなたの環境での性能特性を調べる
著者：
野村総合研究所 平野 耕一
2005/6/20
前のページ
1
2
3
4
次のページ
DBT-1をPostgreSQLに適用すると見えてくるもの
DBT-1をPostgreSQLに適用する前に、性能測定を通じて何を把握したいのか、を明らかにする必要がある。それもなるべく具体的であればあるほどよい。具体化に具体化を重ねていくと、究極的には自分で開発した本物のWebアプリケーションを使って性能測定をすればいいのではあるが、開発に入る前に、限られた予算・ハードウェア資源などで目標の性能が出るかどうかのおおまかな目安を把握することがベンチマークの心である。
この思考プロセスの簡単な仮想ケースを以下に挙げる。
手元にあるPCサーバは、知り合いから譲り受けたD社EP4600、プロセッサはXeonプロセッサ2.40GHz（IA32）2CPU、メモリは4GB、ハードディスクは内蔵ドライブベイにUltra 320 SCSI 72GB 8台を搭載している。
このPCサーバ上で、PostgreSQL 7.4.6を使ったWebアプリケーションを動作させたい。アプリケーションは、会員向けの食料・生活用品の宅配注文受付アプリケーションである。会員数は現在300人であるが、今後2年間で1,000人にする見込みである。
取扱商品数は、毎週さまざまな生鮮食料品を販売することもあって、今後2年間でのべ10,000点を扱うことになる。
会員は、週に2回程度このサイトに訪れ、発注していく。
週2回の注文締め切りの前日夜22時から24時までが注文のピークであり、会員の1/2が同時に訪問してくることが過去の経験でわかっている。各顧客のWebページでのクリックの間隔は平均7.2秒である。
ピーク時でも平均応答時間は3秒以内に抑えたい。
もちろん、いくらWebトランザクション系のベンチマークといえども、あなたが実際に開発するWebシステムとは大きく異なるかもしれない。ただ、おおまかな性能の見積もりを出すために、そこの部分は目をつぶって先に進むとする。
DBT-1をPCサーバ上で動かし、顧客数1,000人、商品数10,000点、同時接続ユーザ数を少し多めに見積もって600、接続ユーザのトランザクション間隔（クリックとクリックの間隔）は7.2秒のもとで、平均応答時間が3秒以内であることを確認する、いや、実際のWebアプリケーションとDBT-1の違いからくる誤差のことを考えて、少し厳しめに1.5秒以内であることを確認できれば、データベースサーバの性能的にはOKということになる。
では報告書にしたがって、PCサーバにLinux、そして今回の評価の対象であるPostgreSQL 7.4.x、DBT-1のパッケージをインストールして、実際にベンチマークを動かした結果を紹介しよう。
何も考えずにDBT-1を動かしたら
前節で仮定した、あなたのWebシステムの性能要件に合わせてDBT-1を構成する。DBT-1は、ベンチマークを動かす際のデータベースのサイズをコンフィギュアラブルに設定可能である。データベースのサイズを決定するファクターとして、ITEM（商品）数と、CUSTOMER（顧客）数がある。あなたの要件にしたがってこれらを10,000、1,000とする（参考：この設定で生成されるデータは、テキスト換算で約3GB）。
このサイズのデータベースをDBT-1の機能を使ってPostgreSQL上に作成、DBT-1の「Think Time」というパラメータ（トランザクションとトランザクションの間隔）を7.2秒としよう。
そして、あなたのWebシステムに接続しているユーザを少しずつ増加させていくとどういう性能特性になるのか（平均応答時間や1秒あたりの処理トランザクション数など）を把握するために、DBT-1でいうEmulated User（EU）の値を200の場合、400の場合、600の場合（先ほどの仮定ではエンドユーザの同時接続数600で平均応答時間が1.5秒以内とした）、800の場合…として、とりあえずそれぞれ20分負荷をかけてみてみよう。
ここでは何も考えずにデフォルトのPostgreSQLの設定、すなわちチューニングも何もしない状態で測定した結果の例を図1に示す。その他の細かい設定は報告書に記述されているが、代表的なものだけ言っておくと、DBT-1はWeb 3階層モデルを模したモードで動作、OSはKernel 2.4系、DBMSはPostgreSQL 7.4.6、データベースのデータ領域は、72GBのSCSIディスク6本をRAID0で構成してある。
図1：デフォルトの設定での性能特性
横軸は、エンドユーザの同時接続数にあたるEmulated User（EU）、縦軸にはそれぞれのEUでのスループット（注2）とエンドユーザから見たデータベースの平均応答時間をプロットしてある。EUが増加するにしたがって、平均応答時間は大きくなっている。
※注2：
1秒あたりの処理トランザクション数、DBT-1用語ではBogo Transaction（BT）/secと呼ぶ。
あなたの性能要件「EUが600の時に平均応答時間が1.5秒以内」を満たしているかというと、EU=600の平均応答時間は3秒弱で残念ながらNGである。PostgreSQL 7.4.6では今回のシステムには耐えられない、という結論になるかというと、決してそうではない。
この記事を読まれている方の多くがご存知のデータベースチューニングで、性能は必ず向上するはずである。なぜならば、この測定時のPostgreSQLの設定は、一昔前のPCサーバのような今から考えると貧弱なハードウェア上でも動作するようにかなり控え目に設定されているからである。いや、他にも上記測定では見えていないことがあるかもしれない。
前のページ
1
2
3
4
次のページ
著者プロフィール
株式会社野村総合研究所 平野 耕一
大英帝国の大学院に私費留学中、研究費がなく、大学教員のLinuxマシンを複数台連結し、夜中にこっそり大量の科学計算を行ったのがオープンソースとの出会い。現在は米国西海岸のNRI Pacific, Inc.に出向中。3才になる双子の父でもある。趣味は自転車通勤。
INDEX
第6回：PostgreSQLは使えるのか？ 〜 あなたの環境での性能特性を調べる
はじめに
DBT-1をPostgreSQLに適用すると見えてくるもの
データベースのチューニング
チューニング後の性能特性
