HOTの効果 (2)

更新処理性能が大幅アップ！ - DBT-2 -

DBT-2は、DBサイズとユーザ数を変えることで負荷を調節します(DBサイズとユーザ数は連動します)。今回は、PostgreSQLの新旧のバージョン双方で、負荷をどんどん高くしていき、どこまでスループット(単位時間あたりの処理数)が出るのかを調べました(図1)。

図1. DBT-2測定によるスループットの変化

8.2.4と比べ、スループットが2500→3300と約30%上昇しています。これだけも随分とインパクトがありますね。次は、トランザクションのレスポンスタイムを見てみましょう（図2）。PostgreSQL8.2.5と8.3.0で同じ負荷で測定をします。このとき、8.2.5にとってはやや過負荷な状態となっています。

図2. 8.2.5(上)と8.3.0(下)のDBT-2測定中のレスポンスタイム

図2の8.3.0のグラフ(下図)は、縦軸のスケールが8.2.5と比べて小さくなっているので注意して下さい。どうですか？全体的なレスポンスタイムを見ると、同じ負荷状態において8.3.0の方が圧倒的に安定しています。更新処理コストの軽減により、レスポンスタイム、スループットともに大幅な向上が見られます。

【コラム】チェックポイントについて

DBT-2測定時の8.2.5のレスポンスタイムグラフで、スパイク状の悪化が確認できますね。これは「チェックポイント」が実施されているために発生しています。チェックポイントは、メモリ上のデータとディスク上のデータの同期を取る処理です。更新処理が多いDBT-2では、このチェックポイント処理時に非常に多くの書き込み処理が走ります。そのため、一時的に性能を悪化させることがあります。PostgreSQL8.3.0では、HOTの効果で更新処理によるI/O負荷が軽減されていることに加え、チェックポイント処理を「ゆっくり」と行うための改良が効果を発揮しています。この改良は、I/O負荷の集中を分散させることができ、性能の安定性を向上させるものです。なお、一般的なシステムではここまで顕著にレスポンスの悪化が見えることは稀でしょう。今回の試験では、8.2.5にとっては過剰な負荷をかけているためここまで明確に見ることができます。 また、Linuxの古いkernelを使用している場合には、ファイルシステムのダーティなデータの書き出しパラメータの関係で、より顕著にレスポンスの悪化が見えることもあります。

では、DBT-2測定の最後のデータとして、I/O量の違いを見てみます。先述のレスポンスタイム比較を行った際のI/Oの総量結果を比較してみましょう（図3)。

図3. DBT-2測定で発生したI/O総量の比較

read量は20%、write量は36%の軽減となりました。(ちなみに、この検証時には双方で大きなスループットの差異はありませんでした。) このように、PostgreSQL8.3は、従来では無理だった負荷もなんなく捌くことができています。これはHOTの貢献によるところが大きいのです。

では、次はDBT-1の測定結果を見ていきます。