Redis的時間太長迴應

遇到Redis的非常高的響應延遲，通過redis-cli使用info命令時不能夠輸出信息的點。Redis的時間太長迴應

該服務器從大約200個併發進程處理請求，但它並沒有存儲太多的信息（至少就我們所知）。當服務器響應時，info命令報告大約20-30 MB的已用內存。

當在高反應潛伏期期間在服務器上運行top，CPU使用率徘徊在95 - 100％。

這種行爲有什麼可能的原因？

你的用法是什麼樣的？是否有很多大SORT正在發生？你在產品代碼中使用'KEYS'嗎？你從哪裏運行'MONITOR'？你的持久戰略是什麼？ – 2013-03-07 08:09:15

我們在此實例中禁用了持久性。目前不在任何地方使用任何'KEYS'或'MONITOR'命令。至少在我所知的範圍內，我們也沒有「SORT」。這個實例專用於'rq'（www.python-rq.org）。 – 2013-03-07 08:26:21

僅基於提供的數據提出解釋是困難的，但這裏是我的猜測。我想你已經檢查了明顯的延遲源（與持久化鏈接的延遲源），沒有Redis命令佔用slow log中的CPU，並且Python-rq挑選的作業數據的大小並不是很大。

根據文檔，Python-rq將作業作爲散列對象插入到Redis中，並讓Redis過期相關的鍵（500秒似乎是默認值）以擺脫作業。如果你有一些嚴重的吞吐量，那麼在某個時候，Redis中會有很多項目等待過期。與未完成的工作相比，他們的人數會很高。

您可以通過在項目的數量看在INFO命令的結果將期滿，檢查了這一點。

Redis過期基於惰性機制（在訪問密鑰時應用）和基於密鑰採樣的活動機制，該活動機制在事件循環（僞背景模式，每100毫秒）中運行。關鍵是當活動到期機制運行時，不能處理Redis命令。

爲避免影響客戶端應用程序的性能太多，僅鍵的有限數目的每個能動機構被觸發時被處理（通過默認，10個鍵）。但是，如果發現超過25％的密鑰過期，則會嘗試過期更多密鑰和循環。這是這種概率算法自動將其活動調整爲Redis必須到期的密鑰數量的方式。

當許多密鑰過期時，這種自適應算法會顯着影響Redis的性能。你可以找到更多的信息here。

我的建議是嘗試阻止Python-rq通過設置過期將項目清理委託給Redis。無論如何，這是排隊系統的糟糕設計。

2013-03-07 19:47:47

這聽起來像是一個很好的解決方案。感謝這樣一個精心設計的答案。我會試試看看它是如何工作的。再次感謝！ – 2013-03-08 03:59:28

是的，注意到減少CPU的使用減少時'Job' TTL。非常感謝！ – 2013-03-08 16:36:53

我認爲在Redis過期密鑰時，減少ttl不應該是避免CPU使用率的正確方法。

迪迪埃說，好點的是Python-RQ目前的結構，它代表的清潔工作，以Redis的使用密鑰過期功能。當然，就像迪迪埃說的那樣，這不是最好的方法。（只有當result_ttl大於0時纔會使用）

然後，如果有一組密鑰/作業的到期日期靠近另一個，那麼問題應該會增加，並且可能會在發生突發事件時完成創造就業機會。

但是Python的RQ套到期鍵時作業已在一個工作已完成，

然後，它並沒有太多意義，因爲鍵應該圍繞他們之間有足夠的時間，以避免這個時間展情況

2013-03-08 19:43:18 pfreixes

回答