2

Linux debian で PostgreSQL 8.3 を実行する専用のデータベース サーバーがあります。更新/挿入も頻繁に行われている間、データベースは定期的に大量のデータを照会されています。定期的に、データベースが短時間 (10 秒など) 応答しないと、通常の実行フローに戻ります。

top で気付いたのは、その間、データベースが応答しない限り続く iowait スパイクがあることです。同時に pdflush がアクティブになります。したがって、pdflush は、ダーティ ページとバックグラウンドの比率に基づいて、キャッシュされたメモリ空間からディスクにデータを書き戻さなければならないというのが私の考えです。残りの時間、postgresql が正常に動作する場合、pdflush がアクティブでないため、iowait は発生しません。私の vm の値は次のとおりです。

 dirty_background_ratio = 5
 dirty_ratio = 10
 dirty_expire_centisecs = 3000

私のmeminfo：

MemTotal:     12403212 kB
MemFree:       1779684 kB
Buffers:        253284 kB
Cached:        9076132 kB
SwapCached:          0 kB
Active:        7298316 kB
Inactive:      2555240 kB
SwapTotal:     7815544 kB
SwapFree:      7814884 kB
Dirty:            1804 kB
Writeback:           0 kB
AnonPages:      495028 kB
Mapped:        3142164 kB
Slab:           280588 kB
SReclaimable:   265284 kB
SUnreclaim:      15304 kB
PageTables:     422980 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
WritebackTmp:        0 kB
CommitLimit:  14017148 kB
Committed_AS:  3890832 kB
VmallocTotal: 34359738367 kB
VmallocUsed:    304188 kB
VmallocChunk: 34359433983 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
HugePages_Surp:      0
Hugepagesize:     2048 kB

ダーティページがメモリに留まる期間（dirty_expire_centisecs）を微調整して、iowaitスパイクを時間的に均等に分割することを考えています（より定期的にpdflushを呼び出して、より小さなデータのチャンクをディスクに書き込みます）。他に提案された解決策はありますか？

4

1 に答える 1

5

postgresql がチェックポイントを設定しているときに、IO スパイクが発生する可能性があります。チェックポイントをログに記録することでそれを確認し、それらがサーバーの応答の欠如と一致するかどうかを確認できます。

その場合は、チューニングcheckpoints_segmentsと checkpoint_completion_targetが役立つ可能性があります。それに関するウィキのアドバイスと、 WAL構成に関するドキュメントを参照してください。

于 2012-07-12T10:36:29.447 に答える