-
自身因素
- api或數據結構使用不合理:例如對一個上萬元素的hash結構執行hgetall操作，數據量造成堵塞。
- 慢查詢
- 大對象
a. 數據庫清零過后執行redis-cli --bigkeys命令的執行結果，系統沒有查詢到大的對象
127.0.0.1:6379> flushall OK 127.0.0.1:6379> [root@localhost etc]# redis-cli --bigkeys # Scanning the entire keyspace to find biggest keys as well as # average sizes per key type. You can use -i 0.1 to sleep 0.1 sec # per 100 SCAN commands (not usually needed). -------- summary ------- Sampled 0 keys in the keyspace! Total key length in bytes is 0 (avg len 0.00) 0 strings with 0 bytes (00.00% of keys, avg size 0.00) 0 lists with 0 items (00.00% of keys, avg size 0.00) 0 sets with 0 members (00.00% of keys, avg size 0.00) 0 hashs with 0 fields (00.00% of keys, avg size 0.00) 0 zsets with 0 members (00.00% of keys, avg size 0.00) [root@localhost etc]#
寫入數據，執行大對象查詢命令，發現String類型name為當前最大對象，確定了大對象，這樣我們可以對它進行調整或縮減，分成多個小對象
[root@localhost etc]# redis-cli 127.0.0.1:6379> set name itxds OK 127.0.0.1:6379> exit [root@localhost etc]# redis-cli --bigkeys # Scanning the entire keyspace to find biggest keys as well as # average sizes per key type. You can use -i 0.1 to sleep 0.1 sec # per 100 SCAN commands (not usually needed). [00.00%] Biggest string found so far 'name' with 5 bytes -------- summary ------- Sampled 1 keys in the keyspace! Total key length in bytes is 4 (avg len 4.00) Biggest string found 'name' has 5 bytes 1 strings with 5 bytes (100.00% of keys, avg size 5.00) 0 lists with 0 items (00.00% of keys, avg size 0.00) 0 sets with 0 members (00.00% of keys, avg size 0.00) 0 hashs with 0 fields (00.00% of keys, avg size 0.00) 0 zsets with 0 members (00.00% of keys, avg size 0.00)
b.生產環境查看key對應value序列化后的長度
生產環境執行debug object key 查看key對應value序列化后的長度，或strlen key查看key的字節數
c.info commandstats 命令分析命令不合理的開銷時間，返回最近執行命令的調用次數，耗時信息
CPU飽和：redis單線程只能用一個CPU,飽和將無法處理更多命令 可以執行命令redis-cli -h{ip} -p{port} --stat 獲取當前redis使用情況
[root@localhost etc]# redis-cli --stat ------- data ------ --------------------- load -------------------- - child - keys mem clients blocked requests connections 1 808.23K 1 0 140 (+0) 10 1 808.23K 1 0 141 (+1) 10 1 808.23K 1 0 142 (+1) 10 1 808.23K 1 0 143 (+1) 10 1 808.23K 1 0 144 (+1) 10
2.持久化造成阻塞
a.fork阻塞：fork操作做法神掛在RDB和AOF重寫，redis主線程調用fork操作產生共享內存的子進程，柚子進程完成持久化操作，如果fork操作本身耗時過長，將導致主進程阻塞，可以執行info stats命令獲取到latest_fork_usec指標，表示最近一次fork操作的耗時，若操作1s則需優化。
b.aof刷盤阻塞：當開啟aof持久化功能時,文件刷盤的方式一般采用每秒一次,后台線程每秒對aof文件做fsync操作,硬盤壓力過大時,fsync操作需要等待,直到寫入完成如果主線程發現距離上一次的fsync成功超過2秒,為了數據安全性它會阻塞直到后台線程執行fsync操作完成,這種阻塞行為主要是硬盤壓力引起,可查看Redis日志識別出這種情況,當發生這種阻塞行為時。
b.aof刷盤阻塞： 當開啟aof持久化功能時,文件刷盤的方式一般采用每秒一次,后台線程每秒對aof文件做fsync操作,硬盤壓力過大時,fsync操作需要等待,直到寫入完成如果主線程發現距離上一次的fsync成功超過2秒,為了數據安全性它會阻塞直到后台線程執行fsync操作完成,這種阻塞行為主要是硬盤壓力引起,可查看Redis日志識別出這種情況,當發生這種阻塞行為時,會打印如下日志：
亦可查看info persistence統計中的aof_delayed_fsync指標,每次發生aof刷盤阻塞主線程時會累加。
c.HugePage寫操作阻塞(求大佬指教)： 子進程在執行重寫期間利用Linux寫時復制技術降低內存開銷,因此只有寫操作時Redis才復制要修改的內存頁,對於開啟Transparent HugePages的操作系統,每次寫命令引起的復制內存頁單位由4K變為2MB,放大了512倍,會拖慢寫操作的執行時間,導致大量寫操作慢查詢。
3.外因素
A.CPU競爭
a.進程競爭：當redis與其他cpu密集型服務部署在一起時可能發生
b.綁定cpu：由於redis單線程架構,為充分利用多核cpu,一台機器部署多個redis並將redis進程綁定到cpu(可降低cpu上下文切換開銷),當redis父進程fork操作創建子進程進行rdb/aof重寫(很耗cpu) 時,父子進程共享同一cpu,將影響redis的穩定性
B.內存交換：指操作系統把redis使用的部分內存換出到硬盤,導致交換后redis性能急劇下降(內存與硬盤處理速度不在一個數量級),可如下查看內存交換信息獲取redis進程號→cat /proc/進程號/smaps | grep Swap
C.網絡問題：
1)連接拒絕：
a).網絡閃段：網絡割接或者帶寬耗盡
b).連接拒絕：超過客戶端最大連接數
c).連接溢出：指操作系統或redis客戶端在連接時的問題，2種原因：
原因1：進程限制 操作系統會對進程使用的資源做限制，其中之一便是對可打開最大文件數進行控制，ulimit –n可查看,超過則發送too many open files錯誤
原因2：backlog隊列溢出 系統對於特定端口的tcp連接使用backlog隊列保存，redis默認長度為511，通過tcp-backlog參數設置，高並發場景下可增大該值，但必須大於操作系統允許值才生效，系統默認backlog為128，使用echo511>/proc/sys/net/core/somaxconn命令進行修改，可通過netstat -s命令獲取因隊列溢出造成的連接拒絕統計
2)網絡延遲： 可使用redis提供的測試工具進行測試,在redis-cli -h {ip} -p {port}命令后加入參數進行測試：
--latency：持續進行延遲測試,分別統計：最小值、最大值、平均值、采樣次數
--latency-history：統計結果同—latency,但默認每15秒完成一行統計,可通過-i參數控制采樣時間
--latency-dist：使用統計圖的形式展示延遲統計,每1秒采樣一次
3)網卡軟中斷(求大佬指教)：
網卡軟中斷是指由於單個網卡隊列只能使用一個CPU,高並發下網卡數據交互都集中在同一個CPU,導致無法充分利用多核CPU的情況,網卡軟中斷瓶頸一般出現在網絡高流量吞吐的場景
摘自大佬：https://www.cnblogs.com/linguoguo/p/12046548.html