Question

我们有一个专用的数据库服务器，在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以便将更小的数据块写入磁盘）。还有其他任何建议的解决方案吗？

Answer 1

当postgresql检查点时，可能会发生IO峰值。您可以通过logging checkpoints验证该问题，看看它们是否与服务器的响应不足相符。

如果是这种情况，调整checkpoints_segments和checkpoint_completion_target可能会有所帮助。请参阅wiki's advice有关该问题以及有关WAL configuration的文档。

专用数据库服务器重iowait峰值

1 个答案: