2010年6月29日

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

武田様

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

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

>  ちょっと質問の本題からずれてしまってますが、「負荷対策」に関するご質問とお

> 見受けしましたので私なりの方法をご紹介させていただきました。良かったら参考に
> して下さい。

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

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@xxxxx
> 〒150-0034 東京都渋谷区代官山町20-5 JPR代官山ビル3F
> TEL:03-5784-9477 FAX:03-3461-8344 MOBILE:090-9830-1266
> ===================================================================
>
>
> -----Original Message-----
> From: pgsql-jp-bounces@xxxxx
> [mailto:pgsql-jp-bounces@xxxxx] On Behalf Of Tomohito Koseki
> Sent: Monday, June 28, 2010 4:22 PM
> To: pgsql-jp@xxxxx
> Subject: [pgsql-jp: 40302] Re: SQL処理時間の計測について
>
> 戸川様
> はじめまして、古跡と申します。
>
> > SQL文の実行時間を取得したいのですが、どの取得方法が正しいのか解らない為、
> > ご教授ください。
> >
> > 1.psql で\timingを実行し、計測したいSQL文を流す。
> > 2.explain analyze の処理時間
> > 3.postgresql.conf の log_destination = ’syslog’としたログ出力結果の処
> 理時間
> > 4.pg_stat_statements のSQLプロファイリングより得られる処理時間
> >
> > 現状把握している取得方法は以上になります。
> > それぞれ取得した場合に、実行結果が異なった為、
> > 質問させて頂きました。
>
> どの取得方法を使用しても、基本的には全て正しいです。
> クライアントとサーバ間のデータ通信を含むか含まないかの違いが主に現れているだ
> けです。
>
> 2 と 3 はクライアントとサーバ間のデータ通信は含まれてませんが、
> 1 はクライアントとサーバ間のデータ通信は含まれています。
>
> どれか一つの方法に固定して使用されてはいかがでしょうか?
>
> 4 と 3 は同じになりそうなのですが、顕著な差がでましたでしょうか?
> pg_stat_statements の作者の方からコメントがあるかもしれません。
>
> --
> --------------------------------------
> Tomohito Koseki <koseki@xxxxx>
> SRA OSS, Inc. Japan
> http://www.sraoss.co.jp/
> --------------------------------------
>

/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社 神戸デジタル・ラボ URL http://www.kdl.co.jp
ICTソリューション部
戸川 一成 (Kazunari Togawa) mail:togawa@xxxxx

◆神戸本社
〒650-0033 神戸市中央区江戸町93番 栄光ビル5F
TEL:078-327-2280 / FAX:078-327-2278
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
貴社のWebサイトは安全ですか?
KDLのProactiveDefenseで脆弱性チェックを!
http://www.proactivedefense.jp/


投稿者 xml-rpc : 2010年6月29日 15:32
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/96734
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。