info
能夠使用info [類別]輸出指定類別內容
info命令輸出的數據可分爲10個類別，分別是：
server
clients# Clients
connected_clients:2 #Redis默認容許客戶端鏈接的最大數量是10000。如果看到鏈接數超過5000以上，那可能會影響Redis的性能
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
限制客戶端鏈接數: maxclients 配置能夠配置客戶端鏈接的最大數
這個數字應該設置爲預期鏈接數峯值的110%到150之間，如果鏈接數超出這個數字後，Redis會拒絕並馬上關閉新來的鏈接
memory
# Memory
#實際緩存佔用的內存和Redis自身運行所佔用的內存(如元數據、lua)。
#它是由Redis使用內存分配器分配的內存，因此這個數據並無把內存碎片浪費掉的內存給統計進去
#若是used_memory > 可用最大內存，那麼操做系統開始進行內存與swap空間交換
#當 rss > used ，且二者的值相差較大時，表示存在（內部或外部的）內存碎片。
#內存碎片的比率能夠經過 mem_fragmentation_ratio 的值看出。
#當 used > rss 時，表示 Redis 的部份內存被操做系統換出到交換空間了，在這種狀況下，操做可能會產生明顯的延遲
used_memory:9892187056
used_memory_human:9.21G
#從操做系統上顯示已經分配的內存總量, 包括碎片
# the RSS will stay more near to the peak
# the memory consumed by rss is not released to the OS by redis, but will be reused for additional data
# 好比在某時刻過時了大量數據, used下降, rss不會下降, peak不變, 會是的mem_fragmentation_ratio增大
# redis 釋放的內存, (短時間內)不返回給系統, 以便重用
used_memory_rss:11148713984
used_memory_peak:11236792296
used_memory_peak_human:10.47G
used_memory_lua:35840
#內存碎片率
#內存碎片率稍大於1是合理的，這個值表示內存碎片率比較低，也說明redis沒有發生內存交換。
#但若是內存碎片率超過1.5，那就說明Redis消耗了實際須要物理內存的150%，其中50%是內存碎片率
#如果內存碎片率低於1的話，說明Redis內存分配超出了物理內存，操做系統正在進行內存交換。內存交換會引發很是明顯的響應延遲
mem_fragmentation_ratio:1.13
mem_allocator:jemalloc-3.6.0
persistence
statstotal_connections_received:273
total_commands_processed:105868 #總共處理的命令數
instantaneous_ops_per_sec:0
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:1
evicted_keys:0 #由於maxmemory限制致使key被回收刪除的數量
keyspace_hits:28076
keyspace_misses:52981
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:414
replication
cpu都是累計值, 隨着Redis啓動的時間長度不斷累計上升，並在你重啓Redis服務後清0
used_cpu_sys : Redis 服務器耗費的系統 CPU
used_cpu_user : Redis 服務器耗費的用戶 CPU
used_cpu_sys_children : 後臺進程耗費的系統 CPU
used_cpu_user_children : 後臺進程耗費的用戶 CPU
commandstats
cluster
keyspace回收策略
相關配置maxmemoryCONFIG SET/GET maxmemory 100mb 讀/寫最大內存配置maxmemory 100mb redis.conf 配置若是爲0表示沒有限制maxmemory-policy 回收策略(當內存達到maxmemory限制)CONFIG SET/GET maxmemory-policymaxmemory-samples 回收樣本大小
maxmemory-policy 六種方式volatile-lru：（默認值）從已設置過時時間的數據集（server.db[i].expires）中挑選最近最少使用的數據淘汰volatile-random：從已設置過時時間的數據集（server.db[i].expires）中任意選擇數據淘汰volatile-ttl ： 從已設置過時時間的數據集（server.db[i].expires）中挑選將要過時的數據淘汰allkeys-lru ： 從數據集（server.db[i].dict）中挑選最近最少使用的數據淘汰allkeys-random：從數據集（server.db[i].dict）中任意選擇數據淘汰noeviction ： 禁止驅逐數據,永不過時，返回錯誤tip:若是數據分佈符合冪定律分佈, 若是你不肯定選擇什麼，allkeys-lru是個很好的選擇volatile-ttl 樣本一樣受maxmemory_samples控制LRU:
lru屬性redisObject 結果包括一個lru屬性, 記錄了對象最後一次被命令程序訪問的時間OBJECT IDLETIME 輸出對象的空轉時間, 是將當前時間減去對象lru, 該命令是特殊實現, 不會修改對象的lru屬性lru 屬性用於配合實現maxmemory-policy中volatile-lru和allkeys-lru回收策略
lru算法在Redis中LRU算法是一個近似算法，默認狀況下，Redis隨機挑選maxmemory-samples個鍵，而且從中選取一個最近最久未使用的key進行淘汰，在配置文件中能夠經過maxmemory-samples的值來設置redis須要檢查key的個數,可是栓查的越多，耗費的時間也就越久,可是結構越精確(也就是Redis從內存中淘汰的對象未使用的時間也就越久~)性能分析
延遲檢測Redis-cli --latency -h 127.0.0.1 -p 6379 結果單位是ms;
診斷響應延遲跟蹤info stats total_commands_processed的變化按期記錄total_commands_processed的值。當客戶端明顯發現響應時間過慢時，能夠經過記錄的total_commands_processed歷史數據值來判斷命理處理總數是上升趨勢仍是降低趨勢延遲的可能緣由;命令隊列裏的命令數量過多，後面命令一直在等待中。幾個慢命令阻塞Redis。方案:使用多參數命令管道命令避免操做大集合的慢命令Redis配置redis.conf 配置實例:slaveof 127.0.0.1 6380
requirepass "hello world" # 若是有空格
經過命令行傳參
./redis-server --port 6380 --slaveof 127.0.0.1 6379
CONFIG REWRITE 重寫配置文件, 會將服務器啓動後的CONFIG SET...寫入配置文件, 參見http://redisdoc.com/server/config_rewrite.html
其餘
監控工具 redis-stathtml
轉自：http://mp.weixin.qq.com/s?__biz=MzA3OTgyMDcwNg==&mid=2650626016&idx=1&sn=29c50ff7ba057ea87457c559b7160e10&scene=23&srcid=0925D79sw43YU05G4GYC1G0u#rdredis