PostgreSQL分析极其短暂的查询异常缓慢

我使用Zend Framework（PHP）和postgresql作为会话存储后端。有时我会得到像这样的日志：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查询解析器速度问题？

一些技术背景：

我使用PostgreSQL 8.4.9在CentOS 6.0，这是2个10Core英特尔机128 GB RAM。此时Cpu仅被使用了20％ - 25％。磁盘读取/写入速度非常快。 log_min_statement = 500

来源

2012-03-09 krawiec.a

锁定目录？缺少shared_buffers？尝试看看锁定列表，也许使用准备好的语句。 – wildplasser 2012-03-09 11:42:33

我'shared_buffers = 32GB'。在这种情况下，我无法使用准备好的语句。可悲的是不知道如何在线监控锁。这种情况一天发生几次，而且通常在没有我的情况下就会发现。 – 2012-03-09 11:55:05

打我。也许你应该*低* shared_mem ;-) – wildplasser 2012-03-09 12:04:20

我对在例的测试盒时类似的情况：

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

的PostgreSQL依赖于2层的数据的高速缓存的：

共享池，通过shared_buffers指定;
通过effective_cache_size指定的操作系统缓存，能否告诉我们您在这里的价值？

为了了解究竟怎么回事您的系统上，你应该监测：

CPU使用率;
内存使用情况;
IO和交换卷。

通过显示器我的意思不只是着眼于当前值，而是使用工具，如sar，iostat，vmstat和一致好评，有，比如说结合，RRDtool更好的数据分析。然后查看生成的报告，了解您在简单查询中观察到不必要的延迟的时间段。

我有一种感觉，你有IO问题，但不看更多的系统和报告不能告诉更多。

我会建议：

设置监控和审查生产报告;
在类似的方框上创建备用数据库，以便使用不同的设置。（我假设你有适当的数据库和WAL备份来做到这一点。）我会研究：内存，自动清理，检查点和WAL设置。
考虑升级到PostgreSQL 9.1，你有2个主要版本落后。

来源

2012-04-12 08:00:07 vyegorov

1）本机是专门为PostgreSQL的 2）无RAM交换 3）大量的缓冲区和缓存 4）监控所有 5）不断完善的查询计划:) 6）复制也不会升级是相当不因现场要求我已经想出了答案。我会在几分钟内写出来。 – 2012-04-16 09:37:30

这种情况似乎是：大量的长idle'ing交易，即<IDLE>在交易。我们设法摆脱了其中大部分。结果非常出色。

令人遗憾的是应用逻辑有缺陷的主要原因。我指的是交易的一部分看起来像：

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

由于行版本控制子系统不得不保留大量旧版本的行组成，该系统已经变得越来越少应答（每个简单的查询不得不寻找合适的行版本）。

来源

2012-04-16 11:05:43

好的旧锁。最好将会话查找保存在不同的数据库事务中。 – 2012-09-29 02:24:42

PostgreSQL分析极其短暂的查询异常缓慢

回答

相关问题