經過redis命令實現性能監控

Redis介紹html

Redis是一種高級key-value數據庫。它跟memcached相似,不過數據能夠持久化,並且支持的數據類型很豐富。有字符串,鏈表、哈希、集合和有序集合5種。支持在服務器端計算集合的並、交和補集(difference)等,還支持多種排序功能。因此Redis也能夠被當作是一個數據結構服務器。Redis的全部數據都是保存在內存中,而後不按期的經過異步方式保存到磁盤上(這稱爲「半持久化模式」);也能夠把每一次數據變化都寫入到一個append only file(aof)裏面(這稱爲「全持久化模式」)。git

Redis監控redis

首先判斷客戶端和服務器鏈接是否正常數據庫

# 客戶端和服務器鏈接正常,返回PONG
redis> PING
PONG
 
# 客戶端和服務器鏈接不正常(網絡不正常或服務器未能正常運行),返回鏈接異常
redis 127.0.0.1:6379> PING
Could not connect to Redis at 127.0.0.1:6379: Connection refused

Redis 監控最直接的方法就是使用系統提供的 info 命令,只須要執行下面一條命令,就能得到 Redis 系統的狀態報告。api

Redis 監控最直接的方法就是使用系統提供的 info 命令,只須要執行下面一條命令,就能得到 Redis 系統的狀態報告。

結果會返回 Server、Clients、Memory、Persistence、Stats、Replication、CPU、Keyspace 8個部分。從info大返回結果中提取相關信息,就能夠達到有效監控的目的。服務器

先解釋下各個參數含義網絡

# Server
redis_version:2.8.8                     # Redis 的版本
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:bf5d1747be5380f
redis_mode:standalone
os:Linux 2.6.32-220.7.1.el6.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.7                       #gcc版本
process_id:49324                        # 當前 Redis 服務器進程id
run_id:bbd7b17efcf108fdde285d8987e50392f6a38f48
tcp_port:6379
uptime_in_seconds:1739082               # 運行時間(秒)
uptime_in_days:20                       # 運行時間(天)
hz:10
lru_clock:1734729
config_file:/home/s/apps/RedisMulti_video_so/conf/zzz.conf
 
# Clients
connected_clients:1                     #鏈接的客戶端數量
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
 
# Memory
used_memory:821848                       #Redis分配的內存總量             
used_memory_human:802.59K
used_memory_rss:85532672                 #Redis分配的內存總量(包括內存碎片)
used_memory_peak:178987632
used_memory_peak_human:170.70M           #Redis所用內存的高峯值
used_memory_lua:33792
mem_fragmentation_ratio:104.07           #內存碎片比率
mem_allocator:tcmalloc-2.0
 
# Persistence
loading:0
rdb_changes_since_last_save:0            #上次保存數據庫以後,執行命令的次數
rdb_bgsave_in_progress:0                 #後臺進行中的 save 操做的數量
rdb_last_save_time:1410848505            #最後一次成功保存的時間點,以 UNIX 時間戳格式顯示
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
aof_enabled:0                            #redis是否開啓了aof
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
 
# Stats
total_connections_received:5705          #運行以來鏈接過的客戶端的總數量
total_commands_processed:204013          # 運行以來執行過的命令的總數量
instantaneous_ops_per_sec:0
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:34401                       #運行以來過時的 key 的數量
evicted_keys:0                           #運行以來刪除過的key的數量
keyspace_hits:2129                       #命中key 的次數
keyspace_misses:3148                     #沒命中key 的次數
pubsub_channels:0                        #當前使用中的頻道數量
pubsub_patterns:0                        #當前使用中的模式數量
latest_fork_usec:4391
 
# Replication
role:master                              #當前實例的角色master仍是slave
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
 
# CPU
used_cpu_sys:1551.61
used_cpu_user:1083.37
used_cpu_sys_children:2.52
used_cpu_user_children:16.79
 
# Keyspace
db0:keys=3,expires=0,avg_ttl=0             #各個數據庫的 key 的數量,以及帶有生存期的 key 的數量

內存使用數據結構

若是 Redis 使用的內存超出了可用的物理內存大小,那麼 Redis 極可能系統會被殺掉。針對這一點,你能夠經過 info 命令對 used_memory 和 used_memory_peak 進行監控,爲使用內存量設定閥值,並設定相應的報警機制。固然,報警只是手段,重要的是你得預先計劃好,當內存使用量過大後,你應該作些什麼,是清除一些沒用的冷數據,仍是把 Redis 遷移到更強大的機器上去。app

持久化異步

若是由於你的機器或 Redis 自己的問題致使 Redis 崩潰了,那麼你惟一的救命稻草可能就是 dump 出來的rdb文件了,因此,對 Redis dump 文件進行監控也是很重要的。能夠經過對rdb_last_save_time 進行監控,瞭解最近一次 dump 數據操做的時間,還能夠經過對rdb_changes_since_last_save進行監控來得到若是這時候出現故障,會丟失(即已改變)多少數據。

Keys

經過獲取Keyspace中的結果獲得各個數據庫中key的數量

QPS

即每分鐘執行的命令個數,即:(total_commands_processed2-total_commands_processed1)/span,爲了實時獲得QPS,能夠設定腳本在後臺運行,記錄過去幾分鐘的total_commands_processed。在計算QPS時,利用過去的信息和當前的信息得出QPS的估計值。

參考

redis info命令中各個參數的含義

ping

相關文章
相關標籤/搜索