PostgreSQLは非常に短いクエリの構文解析が非常に遅い

Question

私はZend Framework（PHP）とpostgresqlをセッションストレージバックエンドとして使用しています。時々、私はこのようなログを得ています：

Mar 8 11:07:00 myhost postgres[79149]: [30640132-1] 0 LOG: 00000: duration: 1401.742 ms parse pdo_stmt_00000005: SELECT "sessions".* FROM "php"."sessions" WHERE ((("sessions"."id" = '3d5tmqutaeuivtf8a1udfa5i04'))) 
Mar 8 11:07:00 myhost postgres[79150]: [30640151-1] 0 LOG: 00000: duration: 1400.083 ms parse pdo_stmt_00000007: SELECT "sessions".* FROM "php"."sessions" WHERE ((("sessions"."id" = 'b2vh1r29vnqg1e3600ther40c3'))) 
Mar 8 11:07:00 myhost postgres[79152]: [30640135-1] 0 LOG: 00000: duration: 1401.261 ms parse pdo_stmt_00000005: SELECT "sessions".* FROM "php"."sessions" WHERE ((("sessions"."id" = '3d5tmqutaeuivtf8a1udfa5i04'))) 
Mar 8 11:07:00 myhost postgres[79147]: [30640166-1] 0 LOG: 00000: duration: 1381.648 ms parse pdo_stmt_00000009: SELECT "sessions".* FROM "php"."sessions" WHERE ((("sessions"."id" = '6uj0955g64mmd9i8ra1q5nbtd5'))) 

テーブルphp.sessionsはいつでも約500-1000行あります。

このステートメントの実行が遅いとして記録されていないので、解析はほとんど「無限」です。

ヒント？誰もがpostgresのクエリパーサーの速度の問題を知っていますか？

一部のハイテク背景：

私はCentOSの6.0でPostgreSQL 8.4.9を使用しています、それは128ギガバイトのRAMで2回10Core Intelマシンです。この時点では、Cpu isは20％〜25％しか使用されていませんでした。ディスクの読み書きは非常に高速です。 log_min_statement = 500

Answer 1

私は例のテストボックスに似たような状況があります。

• CPU-重いプロセスがサーバー上で実行されているが、
• システムは、RAMを集中的に処理するために、RAMをディスクにスワップアウトします。

PostgreSQLは、データ・キャッシュの2層に依存している：

1. 共有プール、shared_buffersを介して指定されました。
2. OSキャッシュは、effective_cache_sizeで指定されていますが、ここであなたの価値について教えてください。

本当にあなたのシステム上で何が起こっているかを理解するために、あなたが監視する必要があります：

• CPU使用率。
• RAM使用率;
• IOとスワップボリューム。

モニターことで私は、現在の値を見ていない意味ではなく、たとえば、と組み合わせるsar、iostat、vmstatと同様に、より優れたデータ分析のためのRRDtoolのようなツールを使用して。そして、簡単なクエリで望ましくない遅延が発生したことを確認して、作成されたレポートを期間にわたってレビューします。

私はあなたがIO問題を抱えていると感じていますが、システムやレポートを見なくてもそれ以上のことは分かりません。

私が推薦する：

1. セットアップのモニタリングとレビューは、レポートを生成します。
2. さまざまな設定で再生するために、同様のボックスにスタンバイデータベースを作成します。 （私はあなたがそれを行うために適切なデータベースとWALのバックアップを持っていると仮定します）私は、メモリ、自動バキューム、チェックポイント、WALの設定を調べます。
3. PostgreSQL 9.1へのアップグレードを検討してください.2つのメジャーリリースがあります。トランザクションで長いidle'ing取引の多く、すなわち<IDLE>：

Answer 2

このケースはあるように思われました。私たちはそのほとんどを取り除くことができました。その結果は抜群です。

主な理由は、悲しいことにアプリケーションロジックの欠陥が発生しました。私は、トランザクションの一部がように見えた意味：

• クエリ
• （待機中のたくさん）...
• を待つ待機
• クエリを開始します
• は、行のバージョン管理サブシステムは、行の古いバージョンの多くを維持しなければならなかったように、システムは、（それぞれ、単純なクエリは、適切な行バージョンを探すために持っていた）少なく応答になってきている

をコミットします。