Centos 5.5での単純なPostgreSQL 8.4.4クエリによる非常に遅いIO

私が見ている奇妙で非常に遅いIOパターンはこれです（の出力iostat -dxk 1 /dev/xvdb1）：

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.99  0.99     7.92     3.96    12.00     1.96 2206.00 502.00  99.41

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.00  0.00     0.00     0.00     0.00     1.00    0.00   0.00 100.40

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.00  0.00     0.00     0.00     0.00     1.00    0.00   0.00 100.40

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.99  0.00     3.96     0.00     8.00     0.99 2220.00 1004.00  99.41

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.00  0.00     0.00     0.00     0.00     1.00    0.00   0.00 100.40

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.99  0.99  0.00     7.92     0.00    16.00     1.14 2148.00 1004.00  99.41

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.00  0.00     0.00     0.00     0.00     2.01    0.00   0.00 100.40

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  1.00  1.00     4.00     8.00    12.00     2.01 1874.00 502.00 100.40

なぜディスクの使用率と待機率が非常に高く、読み取り/書き込み率が非常に低いのか、私にはわかりません。これの理由は何でしょうか？

照会されるテーブルには、いくつかのvarchar列のみがあり、そのうちの1つはlast_nameであり、インデックスが付けられています（実際にlower(last_name)はインデックスが付けられています）。クエリ自体は単純です。

SELECT * FROM consumer_m WHERE lower(last_name) = 'hoque';

これは説明出力です：

                                           QUERY PLAN                                            
-------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on consumer_m  (cost=2243.90..274163.41 rows=113152 width=164)
   Recheck Cond: (lower((last_name)::text) = 'hoque'::text)
   ->  Bitmap Index Scan on consumer_m_last_name_index  (cost=0.00..2215.61 rows=113152 width=0)
         Index Cond: (lower((last_name)::text) = 'hoque'::text)

また、データベースがauto_vacuum上にあるため、明示的なバキューム/分析は実行されなかったことにも注意してください。

デバイスが実際に存在/dev/xvdb1するということは、Xenで実行していることを意味します。ストレージはどのように構成されていますか？基本となるデバイスの競合があり、どのようiostatに見ているの？

可能性としてそれを排除できない限り、ここで、パフォーマンスの低さの渦巻くスピナーを指摘します。

基本的に、このようなパフォーマンスの問題を解決するための全体的なアプローチは、ボトルネックが発生する可能性のあるすべてのレイヤーについて検討し、問題を特定するまで各レイヤーを排除するテストを考案することです。

以下は、多少ランダムな順序での提案です。

1. CentOSでは、Autovacumはデフォルトではオンになっていません。それを有効にするために設定する必要がある複数の設定があります。vacumプロセスが実際に実行されるように再確認してください。必要な設定の1つを見逃してしまいがちです。

2. そのクエリに対して2番目のフィルターステップを実行する必要があることに注意してください。私は次のようなインデックスを検討します：

   CREATE INDEX consumer_m_lower_last ON consumer_m（lower（last_name））;

   クエリと一致し、再チェックを削除します。

3. また、mattdmが指摘しているように、仮想化環境ではiostatを信頼できません。

4. XEN環境でIOの問題がある場合は、おそらくhttp://lonesysadmin.net/2008/02/21/elevatornoop/を確認する必要があります。エレベーターの設定は影響を与える可能性がありますが、それほど大きくはありません。

5. 基盤となるディスクはLVMスナップショットを使用していますか？これは管理の観点からは非常に便利ですが、IOパフォーマンスが低下する可能性があります。これは、使用しているブロックデバイスがスナップショットである場合と、ブロックデバイスのスナップショットが取得されている場合の両方に当てはまります。

これはPostgreSQLの問題ではないかと思いますが、おそらくディスクIOの問題にすぎません。別の回答のコメントにあるように、ディスクIOの問題である場合は、実際にDom0から測定して、発生しているすべての状況を把握する必要があります。

しばらく前に非常によく似た問題があり、ディスクコントローラーの問題であることが判明しました。ディスクアクセスが非常に遅いため、システムはディスクIOの待機中にボトルネックを引き起こしていました（これは非常に高い負荷平均と待機時間として示されましたが、ディスクを待機しているプロセスが他の場合よりも多くのCPUを消費する原因にもなりました。カーネルによって、コントローラが正しく認識されず、高速のSATAコントローラではなく、古い学校のIDEコントローラにフォールバックしていました。

修正はで起動することでした

hda=noprobe hda=none 

/etc/grub.confのカーネル文字列の最後。（もちろん、持っているすべてのディスクを追加してください、ala：hdc=noprobe, hdc=none, hdd=...）