Question

我们有一个功能强大的Postgres服务器（64核，384 GB RAM，16个15k SAS驱动器，RAID 10），并且在白天我们多次重建几个大型数据集，这是非常密集的。 Apache和Tomcat也在同一台服务器上运行。

我们每天都会收到300次这样的警告，同时重建这些数据集，长期延伸，误差平均为2 - 5秒：

2015-01-15 12:32:53 EST [11403]: [10841-1] LOG:  checkpoints are occurring too frequently (2 seconds apart)
2015-01-15 12:32:56 EST [11403]: [10845-1] LOG:  checkpoints are occurring too frequently (3 seconds apart)
2015-01-15 12:32:58 EST [11403]: [10849-1] LOG:  checkpoints are occurring too frequently (2 seconds apart)
2015-01-15 12:33:01 EST [11403]: [10853-1] LOG:  checkpoints are occurring too frequently (3 seconds apart)

以下是相关设置：

checkpoint_completion_target    0.7
checkpoint_segments 64
checkpoint_timeout  5min
checkpoint_warning  30s
wal_block_size  8192
wal_buffers     4MB
wal_keep_segments   5000
wal_level   hot_standby
wal_receiver_status_interval    10s
wal_segment_size    16MB
wal_sync_method     fdatasync
wal_writer_delay    200ms
work_mem    96MB
shared_buffers  24GB
effective_cache_size    128GB

这意味着我们每2到5秒写一个1024 MB的WAL文件，有时会持续15到30分钟。

1）您是否看到我们可以改进的任何设置？如果您需要记录其他设置，请告诉我。

2）我们可以使用“SET LOCAL synchronous_commit TO OFF”;在这些写入密集型事务的开始，让这些WAL写入在后台发生一点点，对其余操作的影响较小？

我们正在重建的数据存储在其他地方，因此，如果电源发生故障并且RAID电池备份没有完成任务，那么一旦数据集再次重建，我们就不会出现任何问题。

将“SET LOCAL synchronous_commit TO OFF”;如果这种情况持续15-30分钟会导致任何问题？或者导致使用WAL发送器的流式复制出现任何问题？

谢谢！

PS。我希望三星开始发售他们的SM1715 3.2 TB PCIe企业级固态硬盘，因为我认为它可以很好地解决我们的问题。

Answer 1

由于wal_level设置为hot_standby，您的服务器正在生成如此多的WAL数据。我假设你需要这个，所以避免警告的最佳选择是增加你的checkpoint_segments。但它们只是 - 警告 - 在批量更新和数据加载过程中看到它们是非常普遍和完全正常的。你恰好经常更新。

更改synchronous_commit不会更改写入wal的内容，而是更改提交返回以允许操作系统缓冲这些写入的时间。

它可能不适用于您的架构，但您可以通过使用未记录的表来进行数据重建来保存一些WAL数据。您的副本将无法访问这些表，但在重建之后，您将能够从未记录的兄弟姐妹更新已记录的表。

Postgres：检查点太频繁发生

1 个答案: