Parsing PostgreSQL对极短查询的解析异常缓慢

我使用Zend Framework（PHP）和postgresql作为会话存储后端。有时我会收到很多这样的日志：

Mar  8 11:07:00 myhost postgres[79149]: [30640132-1] 0 LOG:  00000: duration: 1401.742 ms  parse pdo_stmt_00000005: SELECT "sessions".* FROM "php"."sessions" WHERE ((("sessions"."id" = '3d5tmqutaeuivtf8a1udfa5i04')))
Mar  8 11:07:00 myhost postgres[79150]: [30640151-1] 0 LOG:  00000: duration: 1400.083 ms  parse pdo_stmt_00000007: SELECT "sessions".* FROM "php"."sessions" WHERE ((("sessions"."id" = 'b2vh1r29vnqg1e3600ther40c3')))
Mar  8 11:07:00 myhost postgres[79152]: [30640135-1] 0 LOG:  00000: duration: 1401.261 ms  parse pdo_stmt_00000005: SELECT "sessions".* FROM "php"."sessions" WHERE ((("sessions"."id" = '3d5tmqutaeuivtf8a1udfa5i04')))
Mar  8 11:07:00 myhost postgres[79147]: [30640166-1] 0 LOG:  00000: duration: 1381.648 ms  parse pdo_stmt_00000009: SELECT "sessions".* FROM "php"."sessions" WHERE ((("sessions"."id" = '6uj0955g64mmd9i8ra1q5nbtd5')))

表php.sessions随时都有大约500-1000行

这似乎很奇怪，因为这条语句的执行并没有记录得那么慢，但解析几乎是“无止境的”

有线索吗？有人知道postgres查询解析器的速度问题吗

一些技术背景：

---

我在CentOS 6.0上使用的是PostgreSQL 8.4.9，它是一台2倍10核的Intel机器，内存为128 GB。此时Cpu的使用率仅为20%-25%。磁盘读/写速度非常快。log_min_statement=500

在以下情况下，我在测试箱上有类似的情况：

• CPU密集型进程在服务器上运行
• 系统开始将RAM交换到磁盘上，以进行RAM密集型进程

PostgreSQL依赖于两层数据缓存：

共享池，通过

共享_缓冲区指定
操作系统缓存，通过
有效缓存大小指定，请告诉我们您在这里的值是多少

为了了解系统的实际情况，您应该监控：


CPU使用率
内存使用
IO和交换卷

所谓监控，我的意思是不只是查看当前值，而是使用诸如
sar
、
iostat
、
vmstat
等工具，再加上（比如）更好的数据分析。然后查看生成的报告，查看您在简单查询中观察到的不必要延迟的时间段

我感觉您有IO问题，但如果不查看系统和报告，就无法说出更多信息

我建议：

设置监控和审查生成的报告
在类似的盒子上创建一个备用数据库，以便使用不同的设置。（我假设您有适当的数据库和WAL备份来完成这项工作。）我将研究：内存、自动真空、检查点和WAL设置
考虑升级到PostgreSQL 9.1，您落后了两个主要版本
这种情况似乎是：大量长期闲置的事务，即事务中的。我们设法摆脱了他们中的大多数。而且效果显著

不幸的是，主要原因是应用程序逻辑有缺陷。我的意思是，部分交易看起来像：


开始
查询
查询
等等
。。。（大量等待）
等等
提交

由于行版本控制子系统必须保留大量旧版本的行，因此系统的响应性越来越差（每个简单的查询都必须寻找合适的行版本）。
锁定目录？缺少共享缓冲区？试着看一下锁列表，也许使用准备好的语句。我已经共享了32GB的缓冲区。在这种情况下，我不能使用事先准备好的陈述。遗憾的是，我不知道如何在线监控锁。这种情况一天发生几次，而且经常在我没有注意到的情况下出现。真让我受不了。也许你应该降低共享的_mem；-）无论如何，谢谢你。我不认为降低共享缓冲区是个好主意。。。这是一个巨大的数据库，几乎需要实时访问。我想有一些锁阻止了pgsql的顺利运行。也可能是其他一些受限资源充当了漏斗/热点。至少解析器是一个（合理的）无害的等待场所。1）这台机器专用于PostgreSQL 2）没有RAM交换3）大量缓冲区和缓存4）监控所有5）不断改进查询计划：）6）由于实时需求，复制和升级都不是很重要。我已经找到了答案。我会在几分钟后写的。好的旧锁。最好在不同的db事务中保持会话查找。