PostgreSQL導入に向けての取り組み ～大規模システムへの適用を目指して～ (3)

3.2 性能面の着目点２：スケーラビリティ

ここまで性能とその安定性を検証してきました。 ここでは「コストパフォーマンス」という観点から、CPU スケーラビリティに関する検証結果をご紹介します。

大規模システムでスケールアップの要求を満たせるのかという観点で、参照系トランザクションを主体に構成される TPC-W モデルを参考に作られた DBT-1 というベンチマークプログラムを用いて CPU スケーラビリティを計測してみました。

図3.2-1

IA サーバでは 16 コアまではスケールする事が確認できましたが、4 → 8 コアでのスケーラビリティに比べ、 8 → 16 コアでのスケーラビリティは低くなっており、コストパフォーマンスの観点で PostgreSQL 8.4 は 8 コアマシンで使用するのがお勧めと言えます。

また、今回ご紹介しませんが OS・ハードウェアアーキテクチャの点から、 16 コアを超えるとスケールしなくなるという結果が別の検証の中で見えてきており、注意が必要と考えています。

このスケーラビリティ検証では DBT-1 を用いましたが、TPC-C のような更新系トランザクションモデルで CPU スケーラビリティを計測した場合、 ストレージネックとなり CPU リソースを使い切れない場合があるため注意が必要です。

なお、UNIX のようなハイエンド･マシンで採用されている NUMA 構成で PostgreSQL を使用する場合にも、注意が必要です。 インターコネクト経由でメモリ・アクセスする際のオーバーヘッドからラッチ（メモリ上のデータを読み書きする際の排他制御機構）の競合が多発したため、 十分なスケーラビリティが得られませんでした。 これも、CPU 以外の要因（メモリ・アクセスの遅延）により、スケールしないという事例といえます。

3.3 性能面の着目点３：バッチ処理性能

弊社が携わっているシステムの多くは、日々大量のバッチ処理をしています。 このバッチ処理を業務の閑散期等の限られた時間内に完了するために、バッチ処理性能の向上策を検討しなければなりません。

図3.3-1

通常、バッチ処理は 1 つの大きな処理ロジックを実行しますが、PostgreSQL はマルチプロセスであるため、 このようなバッチ処理の場合、マルチコアサーバでは CPU リソースを有効に使い切れません ^注1。 そこで、1 つの処理を独立した複数の処理に分割し並列実行することで、マルチコアを活用して処理時間の短縮を図ることができます。 ただし、並列度が高いという事は単位時間の処理量も多くなることから、ストレージへの負荷も当然高まります。 適切な並列度は、そのバッチ処理の内容とストレージ性能に応じて異なるので、必ず検証することをお勧めします。 その際は、ストレージネックで処理性能がサチュレーション（飽和）する手前ぐらいの並列度が良いでしょう。 また、バッチ分割単位が「均等」でない場合も、分割単位の大きなバッチに処理が集中し、CPU を有効に活用できないため注意が必要です。

注1.

１つのプロセスに割り当てられたバッチ処理は、仮にマルチ・コア・サーバであったとしても、１つのコアだけで処理を行います。