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

Question

我使用 Zend Framework (PHP) 和 postgresql 作为 session 存储后端。有时我会收到大量这样的日志:

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，它是具有 128 GB RAM 的 2x 10Core Intel 机器。此时 Cpu 仅使用了 20% - 25%。磁盘读/写速度非常快。 log_min_statement = 500

Answer 1

这种情况似乎是:大量长时间闲置的交易，即 in transaction 。我们已经设法摆脱了其中的大部分。结果非常出色。

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

• 开始
• 查询
• 查询
• 等待
• ...(很多等待)
• 等待
• promise

由于行版本控制子系统不得不保留大量旧版本的行，系统的响应速度越来越慢(每个简单的查询都必须寻找合适的行版本)。