Hibernate（デフォルトのC3P0接続プール）とPostgreSQLデータベース（9.1）を備えたPlay Framework 1.2.4で書かれたアプリケーションがあります。
最近、postgresql.conf で低速クエリのログ記録 (>= 100 ミリ秒) を有効にしたところ、いくつかの問題が見つかりました。
しかし、ある特定のクエリを分析して最適化しようとすると、ログの 200 ～ 250 ミリ秒と比較して、psql では非常に高速 (0.5 ～ 1 ミリ秒) であることがわかりました。他のクエリでも同じことが起こりました。
アプリケーションとデータベース サーバーは同じマシン上で実行され、localhost インターフェイスを使用して通信しています。
JDBC ドライバー - postgresql-9.0-801.jdbc4
ログのクエリ期間は、ネットワークのターンアラウンドなどの外部のものを除いたデータベースの処理時間のみを考慮して計算されるため、何が問題なのだろうか.
可能性 1: 遅いクエリが時折またはバーストで発生する場合は、チェックポイント アクティビティである可能性があります。チェックポイント ロギング ( log_checkpoints = on) を有効にし、ログ レベル ( log_min_messages) が「情報」以下であることを確認して、何が表示されるかを確認します。チェックポイントに時間がかかったり、頻繁に発生したりする場合は、チェックポイント/WAL と bgwriter の調整が必要である可能性があります。同じステートメントが常に遅く、他のステートメントが常に適切に実行される場合、これが原因であるとは考えられません。
psql可能性 2: PgJDBC を介して Hibernate が少なくとも時々 and を実行している間PREPAREに直接実行しているため、クエリプランが異なりますEXECUTE(プロトコルレベルで実行されるため、実際のステートメントは表示されません)。このために、クエリのパフォーマンスをPREPARE test_query(...) AS SELECT ...thenと比較しますEXPLAIN ANALYZE EXECUTE test_query(...)。PREPARE のパラメーターは、位置パラメーター ($1、$2 など) の型名です。EXECUTE のパラメータは値です。
準備済みの計画が 1 回限りの計画と異なる場合は、接続パラメーターを介してPgJDBC の準備のしきい値を設定し、サーバー側の準備済みステートメントを使用しないように指示できます。
準備されたステートメントと準備されていないステートメントのプラン間のこの違いは、PostgreSQL 9.2 で解消されるはずです。それは長年の疣贅でしたが、Tom Lane は次のリリースに向けて対処しました。
いくつかの理由が考えられます。まず、遅いクエリが実行されたときにデータベースが非常にビジーであった場合、クエリは遅くなる可能性があります。したがって、将来の分析のために、その時点でのOSの負荷を監視する必要がある場合があります。
次に、SQLの履歴プランが現在のセッションプランと異なる場合があります。したがって、遅いクエリの実際の計画を確認するには、 auto_explainをインストールする必要がある場合があります。
システムのすべての詳細を知らずに断言するのは非常に困難ですが、いくつかの可能性が考えられます。
ポイントは、クエリの実行時間は、どのライブラリまたはアプリケーションがそれを呼び出しているかによって影響を受けないということです。そのため、違いは他の何かから来ているに違いありません。探し続けてください、頑張ってください！