redis-info詳細介紹-慢日誌-淘汰策略-內存滿了怎麼辦

 

1.redis info 簡介

 

a.內存信息

info Memory 查看內存信息
#由Redis分配器分配的內存總量 , byte 單位 
used_memory:5796941936                              	
#以GB爲單位返回由Redis分配器分配的內存總量
used_memory_human:5.40G                             	
#從操作系統的角度，返回 Redis 已分配的內存（俗稱常駐集大小）
used_memory_rss:6010474496                          	
#以GB爲單位返回由Redis 已分配的內存總量
used_memory_rss_human:5.60G 
#Redis 的內存消耗峯值（以字節爲單位）                       
used_memory_peak:5951647064 
#同上                       
used_memory_peak_human:5.54G 
#Lua 引擎所使用的內存大小（以字節爲單位）                	
used_memory_lua:46080      
#同上                         	
used_memory_lua_human:45.00K 
#Lua腳本佔用內存大小
used_memory_scripts:53784
used_memory_scripts_human:52.52K
#內存中已加載的Lua腳本數量
number_of_cached_scripts:95  
#服務器內存                   
total_system_memory:8204460032   
#同上                 	
total_system_memory_human:7.64G                  


#內存碎片率
mem_fragmentation_ratio:1.04                       	
#在編譯時指定的， Redis 所使用的內存分配器。可以是 libc 、 jemalloc 或者 tcmalloc 。 默認jemalloc
mem_allocator:jemalloc-4.0.3                        	
#觸發數據淘汰後的淘汰策略
maxmemory_policy:noeviction	

 

 

b.服務器信息

#redis版本號
redis_version:4.0.10                 
#Git SHA1              			
redis_git_sha1:00000000                            			
#Git dirty flag                 
redis_git_dirty:0 
#redis運行模式                                  			redis_mode:standalone   
#Redis 服務器的宿主操作系統                              			
os:Linux 3.10.0-123.9.3.el7.x86_64 x86_64  
#系統架構（64/32）         		
arch_bits:64                                       			
#Redis 所使用的事件處理機制   
multiplexing_api:epoll                            			
#編譯 Redis 時所使用的 GCC 版本  
gcc_version:4.8.2  
#服務器進程的 PID                                			
process_id:9619    
#Redis 服務器的隨機標識符（用於Sentinel 和集羣)                             
run_id:025a01ccc87317c977a7d0b0a07d3b623dbd25ed   
#TCP/IP 監聽端口  	
tcp_port:6678  
#自 Redis 服務器啓動以來，經過的秒數                                      			
uptime_in_seconds:13126746                         		
#自 Redis 服務器啓動以來，經過的天數
uptime_in_days:155                                 			
hz:10
#以分鐘爲單位進行自增的時鐘，用於LRU 管理
lru_clock:10752870   
#配置文件位置                              			
config_file:/etc/redis.conf                        			
executable:/root/redis-4.0.10/./src/redis-server
config_file:/root/redis-4.0.10/redis6678.conf

 

c.客戶端信息

#已連接客戶端的數量（不包括通過從屬服務器連接的客戶端） 
connected_clients:13                           
#當前連接的客戶端當中，最長的輸出列表    
client_longest_output_list:0   
#當前連接的客戶端當中，最大輸入緩存 
#正在等待阻塞命令                  
client_biggest_input_buf:0     
#(BLPOP、BRPOP、BRPOPLPUSH）的客戶端的數量                
blocked_clients:0                                   

 

d.持久化RDB 和 AOF 的相關信息

#標誌是否正在執行RDB 持久化（0--否）
loading:0    
#上次執行save後鍵值對的變化數量                                    		  rdb_changes_since_last_save:51752
#是否正在執行bgsave（0--否）                  
rdb_bgsave_in_progress:0 
#上次執行save的時間                        	      	
rdb_last_save_time:1571033910                         	
#上次執行bgsave操作的結果 （ok--成功）
rdb_last_bgsave_status:ok  
#上次bgsave消耗的時間（秒）                                 	
rdb_last_bgsave_time_sec:85  
#如果rdb save操作正在進行，則是所使用的時間                            	
rdb_current_bgsave_time_sec:-1                         	
#COW的大小。指的是父進程與子進程相比執行了多少修改， 包括讀取緩衝區，寫入緩衝區，數據修改等
rdb_last_cow_size:79331328                               	


#aof持久化標誌，默認爲0--不執行aof持久化
aof_enabled:0                                     		
#標識aof的rewrite操作是否在進行中
aof_rewrite_in_progress:0   
#標識是否將要在rdb save操作結束後執行                      		
aof_rewrite_scheduled:0  
#上次rewrite操作使用的時間(單位s)                        		
aof_last_rewrite_time_sec:-1
#如果rewrite操作正在進行，則記錄所使用的時間                      		
aof_current_rewrite_time_sec:-1    
#上次執行bgrewrite結果（ok--成功）              		
aof_last_bgrewrite_status:ok   
#上次執行write操作的結果                  		
aof_last_write_status:ok    

 

e.一般統計信息

#啓動後被連接過的總數
total_connections_received:39366  
#啓動後總共執行的命令總數            		
total_commands_processed:13762016680      
#平均每秒執行的命令數           	
instantaneous_ops_per_sec:1017     
#啓動後總共接收輸入的字節數                  	
total_net_input_bytes:1129169422210    
#啓動後總共輸出的字節數              	
total_net_output_bytes:1191209587051
#接收輸入的速率                	
instantaneous_input_kbps:80.30  
#輸出的速率                   	
instantaneous_output_kbps:89.16                    	
#因爲最大客戶端連接書限制，而導致被拒絕連接的個數
rejected_connections:0                            		
#自啓動起過期的key的總數
expired_keys:20200606                                		
#發佈/訂閱頻道數
pubsub_channels:1  
#發佈/訂閱模式數                             		
pubsub_patterns:6
#上次的fork操作使用的時間（單位ms）                                		
latest_fork_usec:122014                            		

 

f.主從信息

#節點角色 
role:master
#從節點數量
connected_slaves:0
#主鍵id
master_replid:0ea9a1ae0e97ee11e76824caa79bbd1dddee2892
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

 

g.集羣信息

# Cluster 是否開啓
cluster_enabled:0

 

 

2.重點

 

a.內存碎片率

mem_fragmentation_ratio:1.04
它是由操系統分配的內存除以Redis分配的內存得出：


當這個值大於1時，表示分配的內存超過實際使用的內存，數值越大，碎片率越嚴重。
當這個值小於1時，表示發生了swap，即可用內存不夠。




 ***** 如果Redis實例的內存使用率超過可用最大內存 (used_memory > 可用最大內存)，那麼操作系統開始進行內存與swap空間交換，把內存中舊的或不再使用的內容寫入硬盤上 (很耗性能)


產生原因 : 
   1.分配器 分配的內存是固定的 , 但是value不固定 


碎片率變高原因 :
	1. value改變 , 內存重新分配後產生碎片
	2. maxmemory 限制 , 導致key被回收


優化 : 
	1. 儘可能使用hash等結構 , 減少key
	2. 設置key的過期時間 ,對於 set , list 等 在key 上設置日期
	3. 開啓快照 : maxmemory 設置爲系統內存 45% , 未開啓 :90%
	4. config set activedefrag yes 設置

 

 

b.redis內存淘汰策略(內存滿後觸發)

redis 	兩種淘汰策略 LRU  ,  LFU(4.0)   
maxmemory_samples  --> 隨機採樣的精度


noeviction:	        如果緩存數據超過了maxmemory限定值，並且客戶端正在執行的命令(大部分的寫入指令，但DEL和幾個指令例外)會導致內存分配，則向客戶端返回錯誤響應
allkeys-lru: 	    對所有的鍵都採取LRU淘汰
volatile-lru: 	    僅對設置了過期時間的鍵採取LRU淘汰
allkeys-random: 	隨機回收所有的鍵
volatile-random: 	隨機回收設置過期時間的鍵
volatile-ttl: 	    僅淘汰設置了過期時間的鍵---淘汰生存時間TTL(Time To Live)更小的鍵
volatile-lfu：	    對有過期時間的key採用LFU淘汰算法
allkeys-lfu：	    對全部key採用LFU淘汰算法




4.0後LFU把原來的key對象的內部時鐘的24位分成兩部分，前16位還代表時鐘，後8位代表一個計數器。


http://www.redis.cn/topics/lru-cache.ht

 

c.redis淘汰策略詳解(redis內存滿觸發)

相關參數 
maxmemory : 該參數即爲緩存數據佔用的內存限制. 當緩存的數據消耗的內存超過這個數值限制時, 將觸發數據淘汰. 該數據配置爲0時,表示緩存的數據量沒有限制, 即LRU功能不生效.
maxmemory_policy : 淘汰策略. 定義參與淘汰的數據的類型和屬性.
maxmemory_samples : 隨機採樣的精度. 該數值配置越大, 越接近於真實的LRU算法,但是數值越大, 消耗的CPU計算時間越多,執行效率越低.(10時候 接近真實)


##流程
redis處理流程
1.客戶端向redis發送消息，redis對命令進行解析，爲命令分配內存。
2.判斷內存是否超出限定值，即maxmemory，如果超過，則按照所選定的淘汰算法，進行內存釋放。
3.當指令爲讀指令時忽略淘汰算法，當爲寫指令，且超出限定值進行內存釋放，若內存釋放失敗則向客戶端返回錯誤響應，如釋放成功則執行寫指令。


##淘汰邏輯 : 
如果淘汰策略是allkeys-random或者volatile-random,則從相應數據庫中隨機選擇一個key進行淘汰.


如果淘汰策略是allkeys-lru或者volatile-lru, 則根據配置的採樣值maxmemory_samples,隨機從數據庫中選擇maxmemory_samples個key, 淘汰其中熱度最低的key對應的緩存數據.


如果淘汰策略是volatile-ttl,則根據配置的採樣值maxmemory_samples,隨機從數據庫中選擇maxmemory_samples個key,淘汰其中最先要超時的key對應的緩存數據.


###redis 3.0 算法改善 
Redis3.0之後又改善了算法的性能，會提供一個待淘汰候選key的pool，裏面默認有16個key，按照空閒時間排好序。更新時從Redis鍵空間隨機選擇N個key，分別計算它們的空閒時間idle，key只會在pool不滿或者空閒時間大於pool裏最小的時，纔會進入pool，然後從pool中選擇空閒時間最大的key淘

 

d.redis過期策略

redis過期策略:
     1.主動刪除。
        1.1 通過定時任務serverCron定期的清理過期的key。
	redis 會將每個設置了過期時間的 key 放入到一個獨立的字典中，以後會定期遍歷這個字典來刪除到期	的 key。
	Redis 默認會每秒進行十次過期掃描（100ms一次），過期掃描不會遍歷過期字典中所有的 key，而是	採用了一種簡單的貪心策略。
	1.從過期字典中隨機 20 個 key；
	2.刪除這 20 個 key 中已經過期的 key；
	3.如果過期的 key 比率超過 1/4，那就重複步驟 1；


     2.被動刪除
        2.1 每次寫入key時，發現內存不夠，調用activeExpireCycle(主動刪除)釋放一部分內存。
        2.2 每次訪問相關的key，如果發現key過期，直接釋放掉該key相關的內存。

 

 

e.命中率

keyspace_hits:8729070802                             	#在main dictionary(todo)中成功查到的key個數
keyspace_misses:1472184257                              	#同上，未查到的key的個數
命中率 = 85%
根據命中率可以考慮 增加 布隆過濾器/布穀鳥過濾器/二級緩存 來增加命中率


OPS : 
instantaneous_ops_per_sec:3317			#每秒執行的命令數


# Keyspace
db0:keys=296804,expires=253017,avg_ttl=61029788	ttl:估算設置生存時間鍵的平均壽命 ms
db1:keys=95,expires=0,avg_ttl=0

 

 

f.slowlog

CONFIG GET slowlog-*  查看詳情
CONFIG SET slowlog-max-len 1024 設置慢查詢日誌隊列大小
CONFIG SET slowlog-log-slower-than 10000  設置記錄時間閾值 單位微秒 默認10毫秒 

 

slowlog get 查詢數量    查看慢日誌
1 : 唯一標識
2.時間戳
3.執行時間 : 微秒