[pgsql-jp: 40306] Re: SQL処理時間の計測について

2010年 6月 29日 (火) 15:32:05 JST

武田様

お世話になっております。
戸川と申します。

ご回答有難うございます。

> 　ちょっと質問の本題からずれてしまってますが、「負荷対策」に関するご質問とお
> 見受けしましたので私なりの方法をご紹介させていただきました。良かったら参考に
> して下さい。

質問の際に目的を記載し忘れておりました。
申し訳ありません。

SQL処理時間の計測の目的は、非機能要件を満たす為の設計・開発中にSQL処理時間を
計測し、アプリ実装後の画面動作でパフォーマンスで問題がでないようにしたい為、
正確なSQL処理時間を計測したかった次第です。

「負荷対策」の際は参考にさせて頂きます。


> 
> 　それぞれによって結果が異なる、これは古跡様のおっしゃるとおり「そういうも
> の」です。

古跡様からのメールに返信しておりますが、基本的にExplain analyzeの結果を
正として進めていければと考えております。
これだと開発者毎に計測できるので。


以上、宜しくお願い致します。


> 　戸川様 古跡様
> 
> 　武田と申します。
> 
> 　SQL実行時間の件、戸川様の求める回答とはちょっと外れてきてしまうかもしれま
> せんが、私はこのように考えています。
> 
> ・「実行時間」はあまりアテにしない。
> →その時点のサーバの負荷や、取り出そうとしているデータがキャッシュに乗ってい
> るか、analyzeされたデータは正しいか、などによって結果は大きく異なるので
> 
> ・analyze直後のexplain（analyzeなし）の結果を参考にする。
> →index利用の有無やjoinのアルゴリズムなどを解読すれば、そのSQLが良いSQLなの
> か悪いSQLなのかは分かるので。
> 
> ・「実行時間」は気にせずexplainの結果が良いプランになるようにする。
> 
> ・当該テーブルの更新頻度に基づき、analyzeのプランを立てる。
> →せっかく良いSQLを書いても、更新頻度の激しいテーブルのため統計情報が老朽化
> しては意味がないので、そうならないような適度な間隔のanalyzeを提示実行する。
> 
> 
> 　逆に、カットオーバー後のシステムが負荷で悲鳴を上げている場合などは、とにか
> く重い箇所から潰していく必要があるので、log_min_duration_statementのみを参考
> に時間かかっているところから潰していったりします。
> 
> 
> 　ちょっと質問の本題からずれてしまってますが、「負荷対策」に関するご質問とお
> 見受けしましたので私なりの方法をご紹介させていただきました。良かったら参考に
> して下さい。
> 
> 　それぞれによって結果が異なる、これは古跡様のおっしゃるとおり「そういうも
> の」です。
> 
> 
> ===================================================================
> 株式会社ユーマインド http://youmind.jp 武田憲太郎 takeda ＠ youmind.jp
> 〒150-0034 東京都渋谷区代官山町20-5 JPR代官山ビル3F
> TEL:03-5784-9477 FAX:03-3461-8344 MOBILE:090-9830-1266
> ===================================================================
> 
> 
> -----Original Message-----
> From: pgsql-jp-bounces ＠ ml.postgresql.jp
> [mailto:pgsql-jp-bounces ＠ ml.postgresql.jp] On Behalf Of Tomohito Koseki
> Sent: Monday, June 28, 2010 4:22 PM
> To: pgsql-jp ＠ ml.postgresql.jp
> Subject: [pgsql-jp: 40302] Re: SQL処理時間の計測について
> 
> 戸川様
> はじめまして、古跡と申します。
> 
> > SQL文の実行時間を取得したいのですが、どの取得方法が正しいのか解らない為、
> > ご教授ください。
> >
> > １．psql で\timingを実行し、計測したいSQL文を流す。
> > ２．explain analyze の処理時間
> > ３．postgresql.conf の log_destination = ’syslog’としたログ出力結果の処
> 理時間
> > ４．pg_stat_statements のSQLプロファイリングより得られる処理時間
> >
> > 現状把握している取得方法は以上になります。
> > それぞれ取得した場合に、実行結果が異なった為、
> > 質問させて頂きました。
> 
> どの取得方法を使用しても、基本的には全て正しいです。
> クライアントとサーバ間のデータ通信を含むか含まないかの違いが主に現れているだ
> けです。
> 
> 2 と 3 はクライアントとサーバ間のデータ通信は含まれてませんが、
> 1 はクライアントとサーバ間のデータ通信は含まれています。
> 
> どれか一つの方法に固定して使用されてはいかがでしょうか？
> 
> 4 と 3 は同じになりそうなのですが、顕著な差がでましたでしょうか？
> pg_stat_statements の作者の方からコメントがあるかもしれません。
> 
> --
> --------------------------------------
> Tomohito Koseki <koseki ＠ sraoss.co.jp>
> SRA OSS, Inc. Japan
> http://www.sraoss.co.jp/
> --------------------------------------
> 

/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
  株式会社 神戸デジタル・ラボ    URL:http://www.kdl.co.jp
  ICTソリューション部
    戸川　一成  (Kazunari Togawa)  mail:togawa ＠ kdl.co.jp
  
  ◆神戸本社
        〒650-0033 神戸市中央区江戸町93番　栄光ビル5F
        TEL:078-327-2280 / FAX:078-327-2278
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
貴社のWebサイトは安全ですか？
KDLのProactiveDefenseで脆弱性チェックを！
  →http://www.proactivedefense.jp/