第3回　PostgreSQLを遅くしている犯人はどこだ？

下垣徹
NTT OSSセンタ
2008/6/9

NTTグループの各社で鳴らした俺たちLinuxトラブルシューティング探偵団は、各社で培ったOSS関連技術を手に、NTT OSSセンタに集められた。普段は基本的にNTTグループのみを相手に活動しているが、それだけで終わる俺たちじゃあない。引き続きOSSに関するトラブルの解決過程を＠ITで連載していくぜ。 　 ソースコードさえあればどんなトラブルでも解決する命知らず、不可能を可能にし、多くのバグを粉砕する、俺たちLinuxトラブルシューティング探偵団！　助けを借りたいときは、いつでもいってくれ！ OS：高田哲生 俺はリーダー、高田哲生。Linuxの達人。俺のようにソースコードレベルでOSを理解している人間でなければ、百戦錬磨のLinuxトラブルシューティング探偵団のリーダーは務まらん。 Web：福山義仁 俺は、福山義仁。Web技術の達人さ。ApacheのようなWebサーバからTomcat、JBossみたいなJava、アプリケーション技術まで、何でも問題を解決してみせるぜ。 DBMS：下垣徹 下垣徹。PostgreSQLの達人だ。開発からサポートまで何でもやってみせらぁ。でも某商用DBMSだけは勘弁な。 HA：田中 崇幸 よぉ！ お待ちどう。俺さまこそHAエキスパート。Heartbeatを使ってクラスタを構成する腕は天下一品！ HAが好きなんて奇人？ 変人？ だから何？ HaHaHaHa!! 　3回目は俺、下垣徹の登場だ。そこらに転がってるツールでも、立派にボトルネックを突き止められることを証明してやるぜ！

関連記事：
	第1回　高負荷なのに片方のサーバにだけ余裕が……なぜ？ http://www.atmarkit.co.jp/flinux/rensai/troubleshoot01/ts01a.html
	第2回　サービス直前の非常事態！ アプリケーションが復帰しない？ http://www.atmarkit.co.jp/flinux/rensai/troubleshoot02/ts02a.html
	データベースチューニング（キーワードINDEX） http://www.atmarkit.co.jp/channel/dbtuning/dbtuning.html

今回の相手はPostgreSQLの性能

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

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

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

注1：テーブル定義やSQLに関しては、dbt1ベンチマークのモデルを一部改変して利用しました

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

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

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

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

図1　チューニングの手法

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

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

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

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

スペック CPU Intel Xeon CPU 2.80GHz×2 メモリ 8Gbytes ディスク SATA 146Gbytes（7200rpm、キャッシュ8Mbytes） OS RHEL 5.1 PostgreSQL PostgreSQL 8.3.1 表1　今回チューニングを行った環境

第2回へ

1/3

Index Linuxトラブルシューティング探偵団 　第3回　PostgreSQLを遅くしている犯人はどこだ？

Page 1 　今回の相手はPostgreSQLの性能 　で、そもそもチューニングって何なのさ？ 　 Page 2 　性能問題の原因を探る2つのステップ 　どのSQLが遅いのか？   そのSQLのどこに時間がかかっているのか？ 　コラム　実行計画が最適かどうかをチェック 　 Page 3 　出力内容を追いかけろ 　こんなに時間がかかる理由は？ 　いざ、絞り込んで問題の解決へ 　常に考えをめぐらせながら解決を

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）