PostgreSQLを遅くしている犯人はどこだ？：Linuxトラブルシューティング探偵団（3）（1/3 ページ）

今回の相手はPostgreSQLの性能

　今回はオープンソースのデータベース管理システム（DBMS）である「PostgreSQL」における性能チューニングの方法について、例を交えて解説します。

　この記事は、実際にとある現場で性能検証をしていた際に問題になったケースを、手元の環境で疑似的に再現させたものです。背景として、Web 3層モデルでオンラインの性能検証を行っていたところ、業務要件で定められたレスポンスタイムで応答が返ってこないという事象が発生していました。そこで、アプリケーションサーバ（APサーバ）とデータベースサーバ（DBサーバ）の間で問題の切り分けを行った結果、APサーバ側のリソースの使用状況に問題がないことから、DBサーバが問題になっていることが明らかになり、PostgreSQLの解析とチューニングに至ったわけです。

　記事の中では実際に問題になったアプリケーションの例までは提示できませんが、その中からエッセンスを抜き出して構成してみました（注1）。読者の皆さんが直面する問題においても、解決に役立てられるのではないかと思います。

で、そもそもチューニングって何なのさ？

　その前にまず、ここで扱おうとしている「性能チューニング」とは何かについて軽くお話ししておきましょう。

　一口に「性能チューニング」といっても、スループットやレスポンスの改善、リソース使用量の削減など、さまざまな観点があります。何のために作業しているのかが分からなくならないようにするためにも、取りかかる際にはあらかじめ、何を目的としたチューニングなのかを意識しておく必要があります。本件でのチューニングは「要件として定められた応答時間以内にSQLが結果を返すこと」が目的です。

　なおチューニングの手法には、「SQLの発行の仕方をチューニングする」「パラメータをチューニングする」「データベースのメンテナンスをしっかり行うことで性能を維持する」など、それぞれ異なる観点の方法があります。これらを、開発フェーズと検討内容で対比させたものが次の図です。

図1　チューニングの手法

　一般に、上流工程で解決されるべき問題を後工程で解決しようとすると、多くのコストが掛かります。例えば、開発を一通り終えた後に性能問題が発覚し、SQLの発行の仕方を見直すなどとなると、書き換えのコストはおろか、試験のやり直しが発生し、そのコストは小さくはありません。性能については、上流工程の段階から十分検討しておきましょう。

　また、チューニングを行う際には、必ず初めに性能目標を定めておきましょう。チューニングを進めていく際、1つの問題を解決するとまた次の問題が浮上してくることは珍しくありません。初めにゴールを決めておかなければ、無限チューニングに陥る可能性があります。事前に性能目標を定めてから作業に入ることを常に意識しておいてください。

　今回の場合、開発プロジェクト側から性能要件として、「DBサーバからAPサーバへのレスポンスタイムが3秒以内であること」という条件が与えられていました。従って、3秒以上時間がかかっているSQLに対策を打たなければなりません。

　今回用いた環境は以下のとおりです。