Postgres DISK IOが非常に高い。すぐに減らすにはどうすればよいですか？

私は使用しているディスクよりも高速なディスクが役立つことを認識していますが、これには投入に時間がかかり、ディスクIOを減らすためにいくつかの緊急対策を使用しようとしています。頂上では、ほぼ常に赤のDSK使用状況が報告されています。これはpostgres 8.3用です。

shared_buffersの設定は24MBですが、サーバーには16GBのRAMがありますが、RAMは完全には利用されていません。私が最初に考えたのは、データベースに必要なだけのRAMを与えることでしたが、その方法はわかりません（これは専用のデータベースサーバーです）。

再起動を必要としないソリューションが望ましいですが、この時点で取得できるものを取り上げます。

ありがとう！

24MBのshared_buffers設定は控えめなデフォルトです。16GBのRAMを使用できる専用データベースの場合は、かなり大きくする必要があると思います。しかし、はい、サイズを変更するにはサーバーを再起動する必要があります。http://wiki.postgresql.org/wiki/Performance_Optimizationは、パフォーマンス構成ガイドラインの出発点として適しています。shared_buffersを4GBまたは6GBに設定する方が合理的と思われます。

Linuxでは、kernel.shmmax sysctl設定（/etc/sysctl.confで、または/ proc / sys / kernel / shmmaxを書き込むだけで）を調整して、このくらいの共有メモリのブロックを割り当てる必要があることに注意してください。要求された量を指定するエラーが表示されない場合は、kernel.shmmaxをそれより高く設定する必要があります。

多くのメモリがあるので、デフォルトのwork_memを高く設定することも考えられます。これにより、ソートやハッシュ（グループ/順序/区別など）のようなものが一時ファイルを使用するよりもメモリで機能する傾向があります。これを行うためにサーバーを再起動する必要はありません。設定ファイルを更新し、サービスをリロードするだけで、新しいセッションが新しい設定を取得します。セッションのデフォルトの作業メモリは1MBです。一度に使用できる最大値を計算し、そのwork_mem * max_client_connections影響を予測できます。

カーネルFSレイヤーがpostgresqlの共有バッファー外のメモリーに多くのページをキャッシュしている可能性が高いことをプランナーに示すために、effective_cache_sizeも増やす必要があります。

等これがあなたが良いスタートを切ることを願っています。

noatimeでディスクを再マウントします

ここに記載されている提案とは別に、自動バキューム設定を確認することもできます。デフォルトでは、約50回の更新後にトリガーされます。データベースが大量の更新/挿入を実行している場合、不必要なバキュームステートメントがトリガーされ、大量のIOが生成されます。

通常の操作中に最大I / Oスループットに非常に近いシステムでは、checkpoint_completion_targetを増やしてcheckpointsからのI / O負荷を減らすことができます。これの欠点は、チェックポイントを長くすると回復時間が影響を受けることです。これは、回復で使用できるように、より多くのWALセグメントを保持する必要があるためです。

詳細はこちらをご覧ください。

postgresqlのdiskioが非常に高い場合は、実行中のステートメント、特にステートメントをチェックし、「ディスクでソート」を行い、適切なインデックスを設定する必要があります。

「Postgresql Performance Tuning」を検索するだけで、どこから始めるべきかが十分にわかります。