Redis 阻塞之外在因素

排查Redis自身原因引起的阻塞原因之後， 如果還沒有定位問題， 需要排查是否由外部原因引起。 圍繞以下三個方面進行排查：

·CPU競争

·記憶體交換

·網絡問題

CPU競争

CPU競争問題如下：

·程序競争： Redis是典型的CPU密集型應用， 不建議和其他多核CPU密集型服務部署在一起。 當其他程序過度消耗CPU時， 将嚴重影響Redis吞吐量。 可以通過top、 sar等指令定位到CPU消耗的時間點和具體程序， 這個問題比較容易發現， 需要調整服務之間部署結構。

·綁定CPU： 部署Redis時為了充分利用多核CPU， 通常一台機器部署多個執行個體。 常見的一種優化是把Redis程序綁定到CPU上， 用于降低CPU頻繁上下文切換的開銷。 這個優化技巧正常情況下沒有問題， 但是存在例外情況，如圖所示。

當Redis父程序建立子程序進行RDB/AOF重寫時， 如果做了CPU綁定，會與父程序共享使用一個CPU。 子程序重寫時對單核CPU使用率通常在90%以上， 父程序與子程序将産生激烈CPU競争， 極大影響Redis穩定性。 是以對于開啟了持久化或參與複制的主節點不建議綁定CPU。

記憶體交換

記憶體交換（swap） 對于Redis來說是非常緻命的， Redis保證高性能的一個重要前提是所有的資料在記憶體中。 如果作業系統把Redis使用的部分記憶體換出到硬碟， 由于記憶體與硬碟讀寫速度差幾個數量級， 會導緻發生交換後的Redis性能急劇下降。 識别Redis記憶體交換的檢查方法如下：

1） 查詢Redis程序号：

# redis-cli -p 6383 info server | grep process_id
process_id:4476      

2） 根據程序号查詢記憶體交換資訊：

# cat /proc/4476/smaps | grep Swap
Swap: 0 kB
Swap: 0 kB
Swap: 4 kB
Swap: 0 kB
Swap: 0 kB
.....      

如果交換量都是0KB或者個别的是4KB， 則是正常現象， 說明Redis程序記憶體沒有被交換。 預防記憶體交換的方法有：