在日志中，我有以下消息：
LOG: checkpoints are occurring too frequently (15 seconds apart)
HINT: Consider increasing the configuration parameter "checkpoint_segments".
此值当前已设置到16，这是
pgtune提供的。我应该考虑哪些设置来提高写入性能？我希望保持尽可能的安全。考虑到传入的数据量，我可以接受在一次失败中丢失一些最近的数据，只要其中的大部分数据是完整的即可。
编辑：我现在正在使用PostgreSQL 9.0，但是我计划升级到9.1。我没有发布硬件细节，因为尽管我承认它们的重要性，但最终我将需要在硬件非常多样化的多台机器上进行此优化。如果硬件对于答案是必不可少的，请给我基本信息，这样我就可以将答案应用于具有不同硬件配置的机器。
#1 楼
每天1 GB的存储量并不是很高。整天传播出去，每秒约有50 KB。较慢的USB拇指驱动器可以解决此问题。我以为它虽然比较爆裂。正如a_horse_with_no_name所建议的那样，增加检查点段。 100左右并不寻常。然后将
checkpoint_timeout增加到1小时，并考虑将checkpoint_completion_target增加到接近1.0（100％）。完成目标告诉PostgreSQL如何在后台积极地执行后台操作，以便在运行检查点之前完成x％的工作，这迫使所有数据立即从WAL中写出，并且会在发生问题时减慢系统对爬网的速度。 br /> 通常不将其设置为100％的原因是多次写入同一块是很常见的，并且通过延迟WAL写到主存储区，可以防止同一块被无缘无故地写入两次。
如果不太可能在超时发生之前多次写入同一块，即您要做的只是插入，然后将其设置得很高就可以提高到0.9左右发生的最坏情况是，您写的频率会比您原本需要的要多一些，但检查点的影响将大大减少。
评论
实际上，写入量几乎是完全一致的：这是硬件监视软件的数据存储，它每秒24x7连续轮询一次。我可以计算出确切的数据速率，但是随着程序员添加和删除监视点，它会有所波动。
–丹尼尔·里昂（Daniel Lyons）
2012年1月6日在6:03
好吧，如果速率是每天1G并且很平稳，那么几乎任何子系统都可以处理写负载，您只想保持平稳即可，将检查点完成目标设置为接近1.0，并且较长的检查点超时应该可以使您满意。
–斯科特·马洛（Scott Marlowe）
2012年1月9日在17:31
#2 楼
在非常“繁重的写入”系统中，您可能会受到高峰活动期间写入WAL的速率的限制。如果您真的可以“接受失败时丢失一些最新数据”，则可以关闭同步提交，当性能对于事务的持久性比完全确定性更重要时，
可能是一个有用的替代方法
如果您可以更改硬件，可以考虑采用以下任何一种方法来优化写入：
基于RAID5的RAID10
许多主轴（可能意味着2.5英寸而不是3.5英寸）示例）
SAS over SATA
15K超过10K驱动器
SSD
--edit
基于您对@Scott出色答案的评论：“写入量实际上几乎完全均匀”，隐含的数据速率为“每秒50 KB”，我怀疑您是否需要做任何可能导致数据丢失的事情。也许这有助于了解您将其他一些配置参数设置为什么。
评论
如果写性能很重要，则操作系统与旋转硬盘驱动器之间的电池供电控制器可能会产生很大的不同。
–斯科特·马洛（Scott Marlowe）
2012年1月6日，下午4:26
#3 楼
您可能还会检查提交的频率/大小：最近我遇到了一个问题，即我试图在单笔交易中更新> 100万条记录。我收到了类似于OP描述的日志消息，但是即使经过几个小时，事务也无法完成。当我将写入分为几个较小的事务（约10,000条记录）时，所需的总时间减少到了15分钟左右。 checkpoint_timeout过去了，保存记录才能取得实质性进展。我不确定该解释是否成立。我仍然收到警告，但是所有写操作最终都会处理。但是，我需要（找到）一种编程解决方法，而不是一种需要重新配置数据库的解决方法。另请参见http://www.postgresql.org/docs/9.3/static/wal-configuration.html
评论
您可以发布您的版本，最好是有关存储硬件的一些详细信息吗？您是否按照建议增加了checkpoint_segments？发生什么事了？
此类问题的另一个绝佳资源是格雷戈里·史密斯（Gregory Smith）的书《 PostgreSQL 9.0 High Performance》。