降低 PostgreSQL 8.4 写入性能

Question

对 OLTP 应用程序适用性的 postgresql 8.4 负载测试导致了令人不快的情况，当数据库的吞吐量随着时间的推移从每秒数千个写入事务显着下降到几乎为零时。在给定的情况下，写入事务是插入/更新/删除数据库事务。用于测试数据库的负载驱动程序在并行线程中执行 SQL 查询，并使用准备好的语句和连接池。在第一次运行测试后的几分钟内，Postgres 性能下降，并且该问题仅在 2 个并行客户端线程中重现。随后的测试执行显示从一开始就降低了吞吐量。仅在写入事务的情况下才检测到降级 - 选择事务不受影响。一段时间后或服务器重新启动后，问题会重现 - 测试达到高吞吐量，然后再次降级。Linux top 没有显示任何 postgres 进程执行任何重要工作，降级后测试期间 CPU 使用率 <1%，io 等待也正常。

用于测试的机器是：

红帽企业 Linux AS 第 4 版（Nahant 更新 6）

8 CPU @ 2GHz

16GB 内存

WAL 和数据位于不同的 SSD 驱动器上

服务器最初配置为专用的 OLTP 事务处理：

选项从默认更改：

最大连接数 = 150

shared_buffers = 4GB

wal_buffers = 16MB

checkpoint_segments = 80

维护工作内存 = 2GB

修改后的内核参数：

内核.shmmax = 8932986880

内核.shmall = 2180905

内核.sem = 500 64000 200 256

禁用和调整 autovacuum 没有给出任何结果。

任何想法如何解决这个问题？

Answer 1

假设这不是VACUUM问题，听起来您有一个未编入索引的FOREIGN KEY. 在批量加载期间，您是否看到 CPU 或磁盘 IO 增加？

对于咯咯的笑声，你能把 a 的输出贴出来VACUUM VERBOSE ANALYZE table_name吗？一个EXPLAIN ANALYZE INSERT ...也可能是与尽可能多的相关模式的一起有用。