美團在Redis上踩過的一些坑-3.redis記憶體佔用飆升
阿新 • • 發佈:2019-02-02
一、現象: 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有些異常。
- client-output-buffer-limit normal 0 0 0
- rename-command FLUSHALL "隨機數"
- rename-command FLUSHDB "隨機數"
- rename-command KEYS "隨機數"
- redis-server
- # Memory
- used_memory:815072
- used_memory_human:795.97K
- used_memory_rss:7946240
- used_memory_peak:815912
- used_memory_peak_human:796.79K
- used_memory_lua:36864
- mem_fragmentation_ratio:9.75
- mem_allocator:jemalloc-3.6.0
- # Clients
- connected_clients:1
- client_longest_output_list:0
- client_biggest_input_buf:0
- blocked_clients:0
- redis-cli -h 127.0.0.1 -p 6379 monitor
- redis-benchmark -h 127.0.0.1 -p 6379 -c 500 -n 200000
- while [ 1 == 1 ]
- do
- now=$(date "+%Y-%m-%d_%H:%M:%S")
- echo "=========================${now}==============================="
- echo " #Client-Monitor"
- redis-cli -h 127.0.0.1 -p 6379 client list | grep monitor
- redis-cli -h 127.0.0.1 -p 6379 info clients
- redis-cli -h 127.0.0.1 -p 6379 info memory
- #休息100毫秒
- usleep 100000
- done