2

我们有一个在 linux debian 上运行 PostgreSQL 8.3 的专用数据库服务器。定期查询数据库以获取大量数据，同时更新/插入也经常发生。数据库会定期在短时间内（如 10 秒）不响应，然后再次进入正常执行流程。

我通过 top 注意到的是，只要数据库没有响应，在此期间就会出现 iowait 峰值。同时 pdflush 被激活。所以我的想法是pdflush必须根据脏页和背景比率将数据从缓存的内存空间写回磁盘。其余时间，当 postgresql 正常工作时，不会发生 iowait，因为 pdflush 不活动。我的 vm 的值如下：

 dirty_background_ratio = 5
 dirty_ratio = 10
 dirty_expire_centisecs = 3000

我的记忆信息：

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会有所帮助。请参阅wiki 的建议以及有关WAL 配置的文档。

于 2012-07-12T10:36:29.447 回答