0

を打つ私はインデックスページの割合を推定するために、次のクエリを実行してインデックスページへ(バッファヒット)ROMメモリを読んでは、ディスクPostgreSQLのパフォーマンス - インデックスページが

select 
    t.schemaname, 
    t.relname as "Table Name", 
    io_i.indexrelname as "Index Name", 
    case when (io_i.idx_blks_hit <> 0 or io_i.idx_blks_read <> 0) then 
    round(io_i.idx_blks_hit/(io_i.idx_blks_hit::numeric + 
    io_i.idx_blks_read::numeric), 4) else null end as "Index Hit Ratio" 
from 
    pg_stat_user_tables t 
    join pg_statio_user_indexes io_i on io_i.relid = t.relid 
order by "Index Hit Ratio" desc; 

から読み取られ、このレートがどこにあるか私には、いくつかのインデックスを持っています低すぎる(0.7未満)。 考えられる理由と改善方法を教えてください。

答えて

1

shared_buffersは、すべてのインデックスを格納するには十分ではないため、クエリがディスク(またはファイルシステムのキャッシュ(OK))をヒットします。

これらのインデックスは頻繁には使用されない可能性があります。そのため、PostgreSQLでキャッシュされないようにすることは理にかなっています。 pg_stat_user_indexesビューでidx_scanをチェックすると、最後の統計リセット以降にインデックスがスキャンされた頻度を確認できます。

shared_buffersをデータベース全体を格納するのに十分に高く設定することができます。それ以外の場合は、shared_buffersを設定するためのアドバイスがあるread the manualです。

これ以外の場合は、パフォーマンスが良く、I/Oシステムに過負荷がかからない限り、何もしません。問題がある場合は、RAMを増やしてみてください。そのオプションが使い尽くされた場合は、より高速なストレージを確保してください。

+0

ありがとうございます。あなたのアドバイスは非常に役に立ちます。なぜなら実際には100%までのI/O利用率が非常に高いからです。 – MaterialGirl

関連する問題