redis超時緣由排查

1.低效操做產生的延遲。單命令操做一半很快不會形成這樣，SORT,LREM, SUNION，keys ，＊ 等操做都會影響響應時間。

 

使用進程監控程序（top, htop, prstat, 等...）來快速查看Redis進程的CPU使用率。若是traffic不高而CPU佔用很高，八成說明有慢操做。(top -p pid)

 

slowlog 查詢引起延遲的慢命令：(默認超過10毫秒就算慢命令) 只針對慢命令進行統計

 

slowly get 10 查看前十條慢命令

 

config get slowlog-log-slower-than  設置慢命令時間（默認10000us） 10ms

 

2.客戶端鏈接數量，默認爲10000 ，超過5000就會影響性能

 

3.客戶端鏈接數的限制

 

4.增強內存管理

 

5.命令處理總數的影響：total_commands_processed

 

6.延遲命令查詢：

 

文中出現的延遲（latency）均指從客戶端發出一條命令到客戶端接受到該命令的反饋所用的最長響應時間

 

redis-cli --latency -h host -p port 

 

7.網絡和通訊引發的延遲

 

當用戶鏈接到Redis經過TCP/IP鏈接或Unix域鏈接，千兆網絡的典型延遲大概200us，而Unix域socket可能低到30us。這徹底基於你的網絡和系統硬件。在通訊自己之上，系統增長了更多的延遲（線程調度，CPU緩存，NUMA替換等等）。系統引發的延遲在虛擬機環境遠遠高於在物理機器環境。

 

8.redis使用優化

 

客戶機和服務器之間的交互也必然消耗系統相關的延遲，所以在使用redis操做時能夠經過捆綁多個命令在一塊兒的方式減小客戶端和服務端的交互次數。聚合命令象MSET/MGET也能夠用做這個目的。

 

9.不要常常的去進行鏈接與斷開的操做，尤爲是基於web的應用。

 

儘量的延長與服務器鏈接的時間

 

10.swap到硬盤操做形成的延遲 /proc/pid

 

由於smaps文件包括有redis進程的多個不一樣的的內存映射區域的使用狀況（進程的內存佈局遠不是線性排列那麼簡單）。

 

cat smaps | egrep '^(Swap|Size)' (grep -e ‘’ -e ‘’)

 

11.AOF 和硬盤I/O操做延遲

 

主redis不建議使用相關的持久化操做，

 

從redis建議打開aof操做

 

由於主從同步是將🐷的內存線dump出來後傳給從，從進行內存中load。之後每次同步就是按期進行dump核load？

 

經過設置AOF相關的appendfsync項，可使用三種不一樣的方式來執行文件同步（也能夠在運行時使用CONFIG SET 命令來修改這個配置）。

 

- appendfsync 的值設置爲no，redis不執行fsync。這種狀況下形成延遲的惟一緣由就是寫操做。這種延遲沒有辦法能夠解決，由於redis接收到數據的速度是不可控的，不過這種狀況也不常見，除非有其餘的進程佔用I/O使得硬盤速度忽然降低。

 

- appendfsync 的值設置爲everysec，每秒都會執行fsync。fsync 由一個單獨線程執行，若是須要寫操做的時候有fsync正在執行redis就會用一個buffer來延遲寫入2秒（由於在Linux若是一個fsync 正在運行那麼對該文件的寫操做就會被堵塞）。若是fsync 耗時過長（譯者注：超過了2秒），即便fsync 還在進行redis也會執行寫操做，這就會形成延遲。

 

- appendfsync 的值設置爲always ，fsync 會在每次寫操做返回成功代碼以前執行（事實上redis會積累多個命令在一次fsync 過程當中執行）。這種模式下的性能表現是很是差勁的，因此最好使用一個快速的磁盤和文件系統以加快fsync 的執行。

 

大多數redis用戶都會把這個值設成 no 或者 everysec。要減小延遲，最好避免在同一個機器上有其餘耗費I/O的程序。用SSD也有益於下降延遲，不過即便不使用SSD，若是能有冗餘的硬盤專用於AOF也會減小尋址時間，從而下降延遲。

 

若是你想診斷AOF相關的延遲緣由可使用strace 命令：

 

sudo strace -p $(pidof redis-server) -T -e trace=fdatasync

 

12.數據過時形成的延遲

 

redis有兩種方式來去除過時的key：

 

- lazy 方式，在key被請求的時候才檢查是否過時。 to be already expired.

 

- active 方式，每0.1秒進行一次過時檢查。

 

active過時模式是自適應的，每過100毫秒開始一次過時檢查（每秒10次），每次做以下操做：

 

- 根據 REDIS_EXPIRELOOKUPS_PER_CRON 的值去除已通過期的key（是指若是過時的key數量超過了REDIS_EXPIRELOOKUPS_PER_CRON 的值纔會啓動過時操做，太少就沒必要了。這個值默認爲10）, evicting all the keys already expired.

 

- 假如超過25%（是指REDIS_EXPIRELOOKUPS_PER_CRON這個值的25%，這個值默認爲10，譯者注）的key已通過期，則重複一遍檢查失效的過程。

 

REDIS_EXPIRELOOKUPS_PER_CRON 默認爲10， 過時檢查一秒會執行10次，一般在actively模式下1秒能處理100個key。在過時的key有一段時間沒被訪問的狀況下這個清理速度已經足夠了，因此 lazy模式基本上沒什麼用。1秒只過時100個key也不會對redis形成多大的影響。

 

總而言之： 要知道大量key同時過時會對系統延遲形成影響。

 

13.redis看門狗形成的延遲

 

CONFIG SET watchdog-period 200 記錄延遲事件

 

redis 單實例最大併發聽說能夠達到寫1w+/s,可是這是在本地操做redis，遠程redis操做至少相差1/3的數據，所以線上業務如今最大也支持7k＋每秒的讀寫操做以及。

 

那麼若是併發上面沒有問題，可是出現redis 的超時問題，就須要進行上面問題的排查啦。

 

reds的客戶端鏈接數；top查看是否reds跑滿了cpu；超時時間的設置(timeout/tcp-keepalive);網絡延遲；數據量傳輸

 

測試qps/tps:

 

 /export/servers/redis-2.8.9/src/redis-benchmark -h 172.24.212.224 -p 6379 -c 50 -n 10000 -d 2

 

50個併發連接，10000個請求，每一個請求2kb。算下來最終的QPS爲59000/s

 

可是估計線上的redis真實的qps和tps是具體須要考慮到如下幾個方面的：

 

1.估計生產的報文大小，使用－d模擬

 

2.使用redis-cli命令查看info total_commands_processed 信息.經過兩次時間差進行計算QPS

 

注意：監控reis的每秒操做數

 

經常使用監控redis命令：

 

info commandstats 查看命令狀態

 

persistence : RDB 和 AOF 的相關信息

 

stats : 通常統計信息

 

replication : 主/從複製信息

 

cpu : CPU 計算量統計信息

 

commandstats : Redis 命令統計信息

 

cluster : Redis 集羣信息

 

keyspace : 數據庫相關的統計信息

 

client list       列出當前鏈接的客戶端

 

redis-cli info clients | grep connected_clients 查看客戶端已鏈接個數

 

redis-cli info memory | egrep '(used_memory_human|used_memory_peak_human)'  查看當前使用內存量，和歷史最高峯值

 

經常使用監控信息：

 

redis-cli -h 172.24.184.1 -p 6379 info stats | grep total_commands   查看啓動到當前處理命令總數

 

redis-cli -h 172.24.184.1 -p 6379 info stats | grep instantaneous_ops_per_sec  每秒操做數

 

redis-cli -h 172.24.184.1 -p 6379 info stats |grep expired_keys                已過時的key數量

 

redis-cli -h 172.24.184.1 -p 6379 info stats |grep net_io_in_per_sec    每秒進出流量(70444byte)0.07M

 

redis-cli -h 172.24.184.1 -p 6379 info stats |grep net_io_out_per_sec

 

redis-cli -h 172.24.184.1 -p 6379 info memory | grep mem_fragmentation_ratio   內存碎片率（若是超大於1表示存在內存碎片／是used_memory_rss與used_memory的比值。小於1說明內存被交換到swap裏面去了）

 

1.slowlog 查詢引起延遲的慢命令：(默認超過10毫秒就算慢命令) 只針對慢命令進行統計

 

slowly get 10 查看前十條慢命令

 

config get slowlog-log-slower-than  設置慢命令時間（默認10000us） 10ms

 

2.客戶端鏈接數量，默認爲10000 ，超過5000就會影響性能

 

3.客戶端鏈接數的限制

 

4.增強內存管理

 

5.命令處理總數的影響：total_commands_processed

 

6.延遲命令查詢：

 

redis-cli --latency 

我的公衆號，不按期更新技術文章：