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分析極其短暫的查詢異常緩慢

回答

相關問題