Redis 阻塞之外在因素

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

·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程序記憶體沒有被交換。預防記憶體交換的方法有：