web-dev-qa-db-ja.com

非常に遅いIO Centos5.5での単純なPostgreSQL8.4.4クエリ

私が見ている奇妙で非常に遅い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にあるため、明示的なバキューム/分析は実行されなかったことにも注意してください。

performancepostgresqlhard-driveiostat
10
ehsanul

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

あなたがそれをおそらく排除することができない限り、それは私が貧弱なパフォーマンスのせいの渦巻くスピナーを指摘するところです。

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

5
mattdm

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

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

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

hda=noprobe hda=none

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

1
Jed Daniels

多かれ少なかれランダムな順序で、いくつかの提案があります：

  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パフォーマンスを損なう可能性があります。これは、使用しているブロックデバイスがスナップショットである場合と、ブロックデバイスのスナップショットが作成されている場合の両方に当てはまります。 。

1
pehrs