1. 程式人生 > >美團在Redis上踩過的一些坑-3.redis記憶體佔用飆升

美團在Redis上踩過的一些坑-3.redis記憶體佔用飆升


 一、現象:     redis-cluster某個分片記憶體飆升,明顯比其他分片高很多,而且持續增長。並且主從的記憶體使用量並不一致。   二、分析可能原因:  1.  redis-cluster的bug (這個應該不存在)  2. 客戶端的hash(key)有問題,造成分配不均。(redis使用的是crc16, 不會出現這麼不均的情況)  3. 存在個別大的key-value: 例如一個包含了幾百萬資料set資料結構(這個有可能)  4. 主從複製出現了問題。  5. 其他原因 三、調查原因:  1. 經查詢,上述1-4都不存在  2. 觀察info資訊,有一點引起了懷疑: client_longes_output_list有些異常。
3. 於是理解想到服務端和客戶端互動時,分別為每個客戶端設定了輸入緩衝區和輸出緩衝區,這部分如果很大的話也會佔用Redis伺服器的記憶體。   從上面的client_longest_output_list看,應該是輸出緩衝區佔用記憶體較大,也就是有大量的資料從Redis伺服器向某些客戶端輸出。 於是使用client list命令(類似於mysql processlist) redis-cli -h host -p port client list | grep -v "omem=0",來查詢輸出緩衝區不為0的客戶端連線,於是查詢到禍首monitor,於是豁然開朗.   monitor的模型是這樣的,它會將所有在Redis伺服器執行的命令進行輸出,通常來講Redis伺服器的QPS是很高的,也就是如果執行了monitor命令,Redis伺服器在Monitor這個客戶端的輸出緩衝區又會有大量“存貨”,也就佔用了大量Redis記憶體。  
四、緊急處理和解決方法 進行主從切換(主從記憶體使用量不一致),也就是redis-cluster的fail-over操作,繼續觀察新的Master是否有異常,通過觀察未出現異常。 查詢到真正的原因後,也就是monitor,關閉掉monitor命令的程序後,記憶體很快就降下來了。 五、 預防辦法: 1. 為什麼會有monitor這個命令發生,我想原因有兩個: (1). 工程師想看看究竟有哪些命令在執行,就用了monitor (2). 工程師對於redis學習的目的,因為進行了redis的託管,工程師只要會用redis就可以了,但是作為技術人員都有學習的好奇心和慾望。 2. 預防方法: (1) 對工程師培訓,講一講redis使用過程中的坑和禁忌 (2) 對redis雲進行介紹,甚至可以讓有興趣的同學參與進來 (3) 針對client做限制,但是官方也不建議這麼做,官方的預設配置中對於輸出緩衝區沒有限制。 Java程式碼  收藏程式碼
  1. client-output-buffer-limit normal 0 0 0  
(4) 密碼:redis的密碼功能較弱,同時多了一次IO (5) 修改客戶端原始碼,禁止掉一些危險的命令(shutdown, flushall, monitor, keys *),當然還是可以通過redis-cli來完成 (6) 新增command-rename配置,將一些危險的命令(flushall, monitor, keys * , flushdb)做rename,如果有需要的話,找到redis的運維人員處理 Java程式碼  收藏程式碼
  1. rename-command FLUSHALL "隨機數"  
  2. rename-command FLUSHDB "隨機數"  
  3. rename-command KEYS "隨機數"  
六、模擬實驗: 1.  開啟一個空的Redis(最簡,直接redis-server) Java程式碼  收藏程式碼
  1. redis-server  
    初始化記憶體使用量如下: Java程式碼  收藏程式碼
  1. # Memory  
  2. used_memory:815072  
  3. used_memory_human:795.97K  
  4. used_memory_rss:7946240  
  5. used_memory_peak:815912  
  6. used_memory_peak_human:796.79K  
  7. used_memory_lua:36864  
  8. mem_fragmentation_ratio:9.75  
  9. mem_allocator:jemalloc-3.6.0  
    client緩衝區: Java程式碼  收藏程式碼
  1. # Clients  
  2. connected_clients:1  
  3. client_longest_output_list:0  
  4. client_biggest_input_buf:0  
  5. blocked_clients:0  
  2. 開啟一個monitor: Java程式碼  收藏程式碼
  1. redis-cli -h 127.0.0.1 -p 6379 monitor  
3. 使用redis-benchmark: Java程式碼  收藏程式碼
  1. redis-benchmark -h 127.0.0.1 -p 6379 -c 500 -n 200000  
4. 觀察 (1) info memory:記憶體一直增加,直到benchmark結束,monitor輸出完畢,但是used_memory_peak_human(歷史峰值)依然很高--觀察附件中日誌 (2)info clients: client_longest_output_list: 一直在增加,直到benchmark結束,monitor輸出完畢,才變為0--觀察附件中日誌 (3)redis-cli -h host -p port client list | grep "monitor" omem一直很高,直到benchmark結束,monitor輸出完畢,才變為0--觀察附件中日誌 監控指令碼: Java程式碼  收藏程式碼
  1. while [ 1 == 1 ]  
  2. do  
  3. now=$(date "+%Y-%m-%d_%H:%M:%S")  
  4. echo "=========================${now}==============================="  
  5. echo " #Client-Monitor"  
  6. redis-cli -h 127.0.0.1 -p 6379 client list | grep monitor  
  7. redis-cli -h 127.0.0.1 -p 6379 info clients  
  8. redis-cli -h 127.0.0.1 -p 6379 info memory  
  9. #休息100毫秒  
  10. usleep 100000  
  11. done  
 完整的日誌檔案: