Redis詳解（7）性能監控：問題分析和優化

對於任何應用服務和組件，都需要一套完善可靠譜監控方案。

尤其redis這類敏感的純內存、高併發和低延時的服務，一套完善的監控告警方案，是精細化運營的前提。

 

一、Redis監控告警的價值

---

redis故障快速通知，定位故障點；對於DBA，redis的可用性和性能故障需快速發現和定位解決。
分析redis故障的Root cause
redis容量規劃和性能管理
redis硬件資源利用率和成本

1、redis故障快速發現，定位故障點和解決故障

當redis出現故障時，DBA應在儘可能短時間內發現告警；如果故障對服務是有損的(如大面積網絡故障或程序BUG)，需立即通知SRE和RD啓用故障預案(如切換機房或啓用emergency switch）止損。

如果沒完善監控告警;假設由RD發現服務故障，再排查整體服務調用鏈去定位；甚於用戶發現用問題，通過客服投訴，再排查到redis故障的問題；整個redis故障的發現、定位和解決時間被拉長，把一個原本的小故障被”無限”放大。

2、分析redis故障的根本原因

任何一個故障和性能問題，其根本“誘因”往往只有一個，稱爲這個故障的Root cause。

一個故障從DBA發現、止損、分析定位、解決和以後規避措施；最重要一環就是DBA通過各種問題表象，層層分析到Root cause；找到問題的根據原因，才能根治這類問題，避免再次發生。

完善的redis監控數據，是我們分析root cause的基礎和證據。

備註：Troubleshtooing定位Root cause，就像醫生通過病人的病歷和檢查報告找到“真正的病竈”，讓病人康復和少受苦，一樣有意思和複雜；或像刑警通過案件的證據分析和推理，尋找那個唯一的真相，一樣驚心動魄。(快看DBA又在吹牛了），其實在大型商業系統中，一次故障輕鬆就達直接損失數十萬（間接損失更大），那“抓住元兇”，避免它再次“作案”，同樣是“破案”。

問題表現是綜合情的，一般可能性較複雜，這裏舉2個例子：

• 服務調用Redis響應時間變大的性能總是；可能網絡問題，redis慢查詢，redis QPS增高達到性能瓶頸，redis fork阻塞和請求排隊，redis使用swap, cpu達到飽和(單核idle過低),aof fsync阻塞，網絡進出口資源飽和等等
• redis使用內存突然增長，快達到maxmemory; 可能其個大鍵寫入，鍵個數增長，某類鍵平均長度突增，fork COW, 客戶端輸入/輸出緩衝區,lua程序佔用等等

Root cause是要直觀的監控數據和證據，而非有技術支撐的推理分析。

• redis響應抖動，分析定位root casue是bgsave時fork導致阻塞200ms的例子。而不是分析推理：redis進程rss達30gb,響應抖動時應該有同步，fork子進程時，頁表拷貝時要阻塞父進程，估計頁表大小xx，再根據內存copy連續1m數據要xx 納秒，分析出可能fork阻塞導致的。（要的不是這種分析）

  說明：糧廠有個習慣，在分析root cause儘量能拿到直觀證據。因爲一旦引入推理步驟，每一步的推理結果都可能出現偏差，最終可能給出錯誤root cause. “元兇”又逃過一劫，它下次作案估計就會更大。所以建議任何小的故障或抖動，至少從個人或小組內部，深入分析找到root cause；這樣個人或組織都會成長快； 形成良好的氛圍。

3、Redis容量規劃和性能管理

通過分析redis資源使用和性能指標的監控歷史趨勢數據；對集羣進行合理擴容(Scale-out)、縮容(Scale-back)；對性能瓶頸優化處理等。

Redis資源使用飽和度監控，設置合理閥值；

一些常用容量指標：redis內存使用比例，swap使用，cpu單核的飽和度等；當資源使用容量預警時，能及時擴容，避免因資源使用過載，導致故障。

另一方面，如果資源利用率持續過低，及時通知業務，並進行redis集羣縮容處理，避免資源浪費。

進一步，容器化管理redis後，根據監控數據，系統能自動地彈性擴容和縮容。

Redis性能監控管理，及時發現性能瓶頸，進行優化或擴容，把問題扼殺在”萌芽期“，避免它”進化“成故障。

4、Redis硬件資源利用率和成本

從老闆角度來看，最關心的是成本和資源利用率是否達標。

如果資源不達標，就得推進資源優化整合；提高硬件利用率，減少資源浪費。砍預算，減成本。

資源利用率是否達標的數據，都是通過監控系統採集的數據。

這一小節，扯了這麼多； 只是強調redis不是隻有一個端口存活監控就可以了。

下面進入主題，怎麼採集redsis監控數。

老闆曾說：監控告警和數據備份，是對DBA和SRE最基礎也是最高的要求；

當服務和存儲達到產品規模後，可認爲“無監控，不服務；無備份，不存儲”。

 

二、Redis監控的內容

---

針對redis監控，可以分爲幾個層面：

1、服務器系統相關：服務器宕機，CPU,

2、redis應用進程。

3、redis性能指標

4、應用的響應時間：Redis慢查詢監控

 

2.1、服務器系統監控

 

1)、服務器存活監控：

2）CPU

• 平均負載 (Load Average): 綜合負載指標(暫且歸類cpu子系統)，當系統的子系統出現過度使用時，平均負載會升高。可說明redis的處理性能下降(平均響應時間變長、吞吐量降低)。
• CPU整體利用率或飽和度 (cpu.busy): redis在高併發或時間複雜度高的指令，cpu整體資源飽和，導致redis性能下降，請求堆積。
• CPU單核飽和度 (cpu.core.idle/core=0): redis是單進程模式，常規情況只使用一個cpu core, 單某個實例出現cpu性能瓶頸，導致性能故障，但系統一般24線程的cpu飽和度卻很低。所以監控cpu單核心利用率也同樣重樣。
• CPU上下文切換數 (cpu.switches)：context swith過高xxxxxx

3）內存和swap

• 系統內存餘量大小 (mem.memfree)：redis是純內存系統，系統內存必須保有足夠餘量，避免出現OOM，導致redis進程被殺，或使用swap導致redis性能驟降。
• 系統swap使用量大小 (mem.swapused)：redis的”熱數據“只要進入swap,redis處理性能就會驟降； 不管swap分區的是否是SSD介質。OS對swap的使用材質還是disk store. 這也是作者早期redis實現VM,後來又放棄的原因。

說明：系統內存餘量合理，給各種緩衝區，fork cow足夠的內存空間。

另一個問題：我的系統使用Redis緩存集羣，”不怕掛，就怕慢“，或redis集羣高可用做得厲害；這樣redis的服務器是否能關閉swap呢？

4）磁盤

• 磁盤分區的使用率 （df.bytes.used.percent)：磁盤空間使用率監控告警，確保有足磁盤空間用AOF/RDB, 日誌文件存儲。不過 redis服務器一般很少出現磁盤容量問題
• 磁盤IOPS的飽和度(disk.io.util)：如果有AOF持久化時，要注意這類情況。如果AOF持久化，每秒sync有堆積，可能導致寫入stall的情況。 另外磁盤順序吞吐量還是很重要，太低會導致複製同步RDB時，拉長同步RDB時間。（期待diskless replication）

5）網絡

• 網絡吞吐量飽和度(net.if.out.bytes/net.if.in.bytes)：如果服務器是千兆網卡（Speed: 1000Mb/s），單機多實例情況，有異常的大key容量導致網卡流量打滿。redis整體服務等量下降，苦於出現故障切換。
• 丟包率 ：Redis服務響應質量受影響

2.2、Redis應用進程監控

1)、端口存活

2)、進程佔用的cpu和內存

3)、網絡連接數

 

2.3、redis性能指標

可以通過info 命令獲取相關性能指標。

info命令輸出的數據可分爲10個類別，分別是：

• server
• clients
• memory
• persistence
• stats
• replication
• cpu
• commandstats
• cluster
• keyspace

我們主要關注信息：

Redis 連接數監控:clients

•  connected_clients 連接個數：客戶端連接個數，如果連接數過高，影響redis吞吐量。常規建議不要超過5000.參考 官方benchmarks

• connected_clients_pct(連接數使用率): 連接數使用百分比，通過(connected_clients/macclients)計算；如果達到1，redis開始拒絕新連接創建。

• rejected_connections(拒絕的連接個數): redis連接個數達到maxclients限制，拒絕新連接的個數。

• total_connections_received(新創建連接個數 ): 如果新創建連接過多，過度地創建和銷燬連接對性能有影響，說明短連接嚴重或連接池使用有問題，需調研代碼的連接設置。
• blocked_clients (list阻塞調用被阻塞的連接個數 ): BLPOP這類命令沒使用過，如果監控數據大於0，還是建議排查原因。

 

Redis內存監控和優化:memory

• used_memory : redis真實使用內存，不包含內存碎片；單實例的內存大小不建議過大，常規10~20GB以內。
• used_memory_pct(redis內存使用比例): 已分配內存的百分比，通過(used_memory/maxmemory)計算；對於redis存儲場景會比較關注，未設置淘汰策略(maxmemory_policy)的，達到maxmemory限制不能寫入數據。
• used_memory_rss (redis進程使用內存大小): 進程實際使用的物理內存大小，包含內存碎片；如果rss過大導致內部碎片大，內存資源浪費，和fork的耗時和cow內存都會增大。
• mem_fragmentation_ratio(redis內存碎片率 ): 表示(used_memory_rss/used_memory)，碎片率過大，導致內存資源浪費；

  說明：

  1、如果內存使用很小時，mem_fragmentation_ratio可以遠大於1的情況，這個告警值不好設置，需參考used_memory大小。

  2、如果mem_fragmentation_ratio小於1，表示redis已使用swap分區

1、因內存交換引起的性能問題

如果Redis實例的內存使用率超過可用最大內存 (used_memory > 可用最大內存)，那麼操作系統開始進行內存與swap空間交換，把內存中舊的或不再使用的內容寫入硬盤上（硬盤上的這塊空間叫Swap分區），以便留出新的物理內存給新頁或活動頁(page)使用。 

如果Redis進程上發生內存交換，那麼Redis和依賴Redis上數據的應用會受到嚴重的性能影響。 通過查看used_memory指標可知道Redis正在使用的內存情況，如果used_memory>可用最大內存，那就說明Redis實例正在進行內存交換或者已經內存交換完畢。

2、跟蹤內存使用率

若是在使用Redis期間沒有開啓rdb快照或aof持久化策略，那麼緩存數據在Redis崩潰時就有丟失的危險。因爲當Redis內存使用率超過可用內存的95%時，部分數據開始在內存與swap空間來回交換，這時就可能有丟失數據的危險。

當開啓並觸發快照功能時，Redis會fork一個子進程把當前內存中的數據完全複製一份寫入到硬盤上。因此若是當前使用內存超過可用內存的45%時觸發快照功能，那麼此時進行的內存交換會變的非常危險(可能會丟失數據)。 倘若在這個時候實例上有大量頻繁的更新操作，問題會變得更加嚴重。

通過減少Redis的內存佔用率，來避免這樣的問題，或者使用下面的技巧來避免內存交換髮生：

• 儘可能的使用Hash數據結構。因爲Redis在儲存小於100個字段的Hash結構上，其存儲效率是非常高的。

• 設置key的過期時間。一個減少內存使用率的簡單方法就是，每當存儲對象時確保設置key的過期時間。

• 回收key。 若是啓用了Redis快照功能，應該設置“maxmemory”值爲系統可使用內存的45%，因爲快照時需要一倍的內存來複制整個數據集，也就是說如果當前已使用45%，在快照期間會變成95%(45%+45%+5%)，其中5%是預留給其他的開銷。 如果沒開啓快照功能，maxmemory最高能設置爲系統可用內存的95%。

當內存使用達到設置的最大閥值時，需要選擇一種key的回收策略，可在Redis.conf配置文件中修改“maxmemory-policy”屬性值。 若是Redis數據集中的key都設置了過期時間，那麼“volatile-ttl”策略是比較好的選擇。但如果key在達到最大內存限制時沒能夠迅速過期，或者根本沒有設置過期時間。那麼設置爲“allkeys-lru”值比較合適，它允許Redis從整個數據集中挑選最近最少使用的key進行刪除(LRU淘汰算法)。Redis還提供了一些其他淘汰策略，如下：

• volatile-lru：使用LRU算法從已設置過期時間的數據集合中淘汰數據。

• volatile-ttl：從已設置過期時間的數據集合中挑選即將過期的數據淘汰。

• volatile-random：從已設置過期時間的數據集合中隨機挑選數據淘汰。

• allkeys-lru：使用LRU算法從所有數據集合中淘汰數據。

• allkeys-random：從數據集合中任意選擇數據淘汰

• no-enviction：禁止淘汰數據。

通過設置maxmemory爲系統可用內存的45%或95%(取決於持久化策略)和設置“maxmemory-policy”爲“volatile-ttl”或“allkeys-lru”(取決於過期設置)，可以比較準確的限制Redis最大內存使用率，在絕大多數場景下使用這2種方式可確保Redis不會進行內存交換。倘若你擔心由於限制了內存使用率導致丟失數據的話，可以設置noneviction值禁止淘汰數據。

 

 

Redis綜合性能監控

redis鍵空間的狀態監控：

• keys（鍵個數 ): redis實例包含的鍵個數。建議控制在1kw內；單實例鍵個數過大，可能導致過期鍵的回收不及時。
• keys_expires（設置有生存時間的鍵個數 ): 是純緩存或業務的過期長，都建議對鍵設置TTL; 避免業務的死鍵問題. （expires字段）
• avg_ttl (估算設置生存時間鍵的平均壽命 ): redis會抽樣估算實例中設置TTL鍵的平均時長，單位毫秒。如果無TTL鍵或在Slave則avg_ttl一直爲0
• evicted_keys (LRU淘汰的鍵個數 ): 因used_memory達到maxmemory限制，並設置有淘汰策略的實例；（對排查問題重要，可不設置告警）
• expired_keys (過期淘汰的鍵個數 ): 刪除生存時間爲0的鍵個數；包含主動刪除和定期刪除的個數。

Redis qps：

• total_commands_processed (redis處理的命令數 ): 監控採集週期內的平均qps, 
  redis單實例處理達數萬，如果請求數過多，redis過載導致請求堆積。
• instantaneous_ops_per_sec(redis當前的qps ): redis內部較實時的每秒執行的命令數；可和total_commands_processed監控互補。

在Redis實例中，跟蹤命令處理總數是解決響應延遲問題最關鍵的部分，因爲Redis是個單線程模型，客戶端過來的命令是按照順序執行的。比較常見的延遲是帶寬，通過千兆網卡的延遲大約有200μs。倘若明顯看到命令的響應時間變慢，延遲高於200μs，那可能是Redis命令隊列裏等待處理的命令數量比較多。 如上所述，延遲時間增加導致響應時間變慢可能是由於一個或多個慢命令引起的，這時可以看到每秒命令處理數在明顯下降，甚至於後面的命令完全被阻塞，導致Redis性能降低。要分析解決這個性能問題，需要跟蹤命令處理數的數量和延遲時間。

 

Redis cmdstat_xxx

redis記錄執行過的所有命令； 通過info all的Commandstats節採集數據.

• cmdstat_xxx (每類命令執行的次數 ): 這個值用於分析redis抖動變化比較有用

以下表示：每個命令執行次數，總共消耗的CPU時長(單個微秒)，平均每次消耗的CPU時長（單位微秒）

# Commandstats
cmdstat_set:calls=6,usec=37,usec_per_call=6.17
cmdstat_lpush:calls=4,usec=32,usec_per_call=8.00
cmdstat_lpop:calls=4,usec=33,usec_per_call=8.25

Redis Keysapce hit ratio

redis鍵空間請求命中率監控，通過此監控來度量redis緩存的質量，如果未命中率或次數較高，可能因熱點數據已大於redis的內存限制，導致請求落到後端存儲組件，可能需要擴容redis緩存集羣的內存容量。當然也有可能是業務特性導致。

• keyspace_hits(請求鍵被命中次數 ): redis請求鍵被命中的次數
• keyspace_misses (請求鍵未被命中次數 ): redis請求鍵未被命中的次數；當命中率較高如95%，如果請求量大，未命中次數也會很多。可參考Baron大神寫的 Why you should ignore MySQL’s key cache hit ratio
• keyspace_hit_ratio(請求鍵的命中率 ):使用keyspace_hits/(keyspace_hits+keyspace_misses)計算所得，是度量Redis緩存服務質量的標準

Redis fork

redis在執行BGSAVE,BGREWRITEAOF命令時，redis進程有 fork 操作。而fork會對redis進程有個短暫的卡頓,這個卡頓redis不能響應任務請求。所以監控fork阻塞時長，是相當重要。

如果你的系統不能接受redis有500ms的阻塞，那麼就要監控fork阻塞時長的變化，做好容量規劃。

• latest_fork_usec (最近一次fork阻塞的微秒數 ): 最近一次Fork操作阻塞redis進程的耗時數，單位微秒。

redis network traffic

redis一般單機多實例部署，當服務器網絡流量增長很大，需快速定位是網絡流量被哪個redis實例所消耗了； 另外redis如果寫流量過大，可能導致slave線程“客戶端輸出緩衝區”堆積，達到限制後被Maser強制斷開連接，出現複製中斷故障。所以我們需監控每個redis實例網絡進出口流量，設置合適的告警值。

說明：網絡監控指標 ，需較高的版本纔有，應該是2.8.2x以後

• total_net_input_bytes:redis網絡入口流量字節數
• total_net_output_bytes:redis網絡出口流量字節數
• instantaneous_input_kbps:redis網絡入口kps 
• instantaneous_output_kbps:redis網絡出口kps 

前兩者是累計值，根據監控平臺1個採集週期(如1分鐘)內平均每秒的流量字節數。

Redis持久化監控

redis存儲場景的集羣，就得 redis持久化 保障數據落地，減少故障時數據丟失。這裏分析redis rdb數據持久化的幾個監控指標。

• rdb_last_bgsave_status 最近一次rdb持久化是否成功:如果持久化未成功，建議告警，說明備份或主從複製同步不正常。或redis設置有”stop-writes-on-bgsave-error”爲yes，當save失敗後，會導致redis不能寫入操作
• rdb_last_bgsave_time_sec最近一次成功生成rdb文件耗時秒數 ):rdb生成耗時反應同步時數據是否增長； 如果遠程備份使用redis-cli –rdb方式遠程備份rdb文件，時間長短可能影響備份線程客戶端輸出緩衝內存使用大小。
• rdb_changes_since_last_save離最近一次成功生成rdb文件，寫入命令的個數):即有多少個寫入命令沒有持久化，最壞情況下會丟失的寫入命令數。建議設置監控告警
• rdb_last_save_time離最近一次成功rdb持久化的秒數: 最壞情況丟失多少秒的數據寫入。使用當前時間戳 - 採集的rdb_last_save_time(最近一次rdb成功持久化的時間戳)，計算出多少秒未成功生成rdb文件

Redis複製監控

不論使用何種redis集羣方案， redis複製 都會被使用。

複製相關的監控告警項：

• redis_role redis角色 ):實例的角色，是master or slave
• master_link_status複製連接狀態 : slave端可查看它與master之間同步狀態；當複製斷開後表示down,影響當前集羣的可用性。需設置監控告警。
• master_link_down_since_seconds複製連接斷開時間長度 ):主從服務器同步斷開的秒數，建議設置時長告警。
• master_last_io_seconds主庫多少秒未發送數據到從庫 ):如果主庫超過repl-timeout秒未向從庫發送命令和數據，會導致複製斷開重連。詳細分析見文章： Redis複製中斷和無限同步問題 。 在slave端可監控，建議設置大於10秒告警
• slave_lag從庫多少秒未向主庫發送REPLCONF命令 : 正常情況從庫每秒都向主庫，發送REPLCONF ACK命令；如果從庫因某種原因，未向主庫上報命令，主從複製有中斷的風險。通過在master端監控每個slave的lag值。
• slave_read_only從庫是否設置只讀 )：從庫默認只讀禁止寫入操作，監控從庫只讀狀態； 
  如果關閉從庫只讀，有寫入數據風險。關於主從數據不一致,見文章分析： Redis複製主從數據不-致
• connected_slaves主庫掛載的從庫個數 ):主庫至少保證一個從庫，不建議設置超過2個從庫。
• repl_backlog_active:複製積壓緩衝區是否開啓 :主庫默認開啓複製積壓緩衝區，用於應對短時間複製中斷時，使用 部分同步 方式。
• repl_backlog_size複製積壓緩衝大小 :主庫複製積壓緩衝大小默認1MB,因爲是redis server共享一個緩衝區，建議設置100MB.

  說明： 關於根據實際情況，設置合適大小的複製緩衝區。可以通過master_repl_offset指標計算每秒寫入字節數，同時乘以希望多少秒內閃斷使用“部分同步”方式。

 

Redis集羣監控

這裏所寫 redis官方集羣方案 的監控指標

數據基本通過cluster info和info命令採集。

• cluster_enabled實例是否啓用集羣模式 ): 通過info的cluster_enabled監控是否啓用集羣模式。
• clusster_state集羣健康狀態 :如果當前redis發現有failed的slots，默認爲把自己cluster_state從ok個性爲fail, 寫入命令會失敗。如果設置cluster-require-full-coverage爲NO,則無此限制。
• cluster_slots_assigned集羣數據槽slots分配情況 :集羣正常運行時，默認16384個slots
• cluster_slots_fail檢測下線的數據槽slots個數 :集羣正常運行時，應該爲0. 如果大於0說明集羣有slot存在故障。
• cluster_size集羣的分片數 ）：集羣中設置的分片個數
• cluster_known_nodes集羣的節點數 ）：集羣中redis節點的個數

 

 

2.4、Redis響應時間監控

響應時間 是衡量一個服務組件性能和質量的重要指標。使用redis的服務通常對響應時間都十分敏感，比如要求99%的響應時間達10ms以內。

因redis的慢查詢日誌只計算命令的cpu佔用時間，不會考慮排隊或其他耗時。

• respond_time_max最長響應時間 ):最長響應時間的毫秒數
• respond_time_99_max ：99%的響應時間長度 ):
• respond_time_99_avg：99%的平均響應時間長度 ():
• respond_time_95_max 95%的響應時間長度 （):
• respond_time_95_avg 95%的平均響應時間長度 ():

響應時間監控的方式建議，最簡單方法，使用 Percona tcprstat

 

Redis慢查詢監控

redis慢查詢 是排查性能問題關鍵監控指標。因redis是單線程模型(single-threaded server),即一次只能執行一個命令，如果命令耗時較長，其他命令就會被阻塞，進入隊列排隊等待；這樣對程序性能會較大。

redis慢查詢保存在內存中，最多保存slowlog-max-len(默認128）個慢查詢命令，當慢查詢命令日誌達到128個時，新慢查詢被加入前，會刪除最舊的慢查詢命令。因慢查詢不能持久化保存，且不能實時監控每秒產生的慢查詢個數。

我們建議的慢查詢監控方法：

1. slowlog-log-slower-than 設置合理慢查詢日誌閥值,, 建議1ms(如果平均1ms, redis qps也就只有1000)
2. slowlog-max-len 設置全理慢查詢日誌隊列長度，建議大於1024個，因監控採集週期1分鐘，建議，避免慢查詢日誌被刪除；另外慢查詢的參數過多時，會被省略，對內存消耗很小
3. slowlog len 每次採集使用獲取慢查詢日誌個數
4. slowlog get 1024  每次彩集使用獲取所慢查詢，並轉存儲到其他地方，如MongoDB或MySQL等，方便排查問題；並分析當前慢查詢日誌最長耗時微秒數。
5. slowlog reset 然後使用把慢查詢日誌清空，下個採集週期的日誌長度就是最新產生的。

redis慢查詢的監控項：

• redis慢查詢日誌個數 （slowlog_len):每個採集週期出現慢查詢個數，如1分鐘出現10次大於1ms的慢查詢
• redis慢查詢日誌最長耗時值 (slowlog_max_time)：獲取慢查詢耗時最長值，因有的達10秒以下的慢查詢，可能導致複製中斷，甚至出來主從切換等故障。

Redis中的slowlog命令可以讓我們快速定位到那些超出指定執行時間的慢命令，默認情況下命令若是執行時間超過10ms就會被記錄到日誌。slowlog只會記錄其命令執行的時間，不包含io往返操作，也不記錄單由網絡延遲引起的響應慢。通常1gb帶寬的網絡延遲，預期在200μs左右，倘若一個命令僅執行時間就超過10ms，那比網絡延遲慢了近50倍。 想要查看所有執行時間比較慢的命令，可以通過使用Redis-cli工具，使用slowlog get命令查看，返回結果的第三個字段以微妙位單位顯示命令的執行時間。

圖中字段分別意思是：

• 1）、日誌的唯一標識符

• 2）、被記錄命令的執行時間點，以 UNIX 時間戳格式表示

• 3）、查詢執行時間，以微秒爲單位

• 4）、執行的命令，以數組的形式排列。完整命令是config get *

 

 

 

三、Redis info詳細詳解

---

# Server
redis_version:3.2.3 #redis版本號
redis_git_sha1:00000000 #git sha1摘要值
redis_git_dirty:0  #git dirty標識
redis_build_id:443e50c39cbcdbe0 #redis構建id
redis_mode:standalone  #運行模式：standalone、sentinel、cluster
os:Linux 3.10.0-514.16.1.el7.x86_64 x86_64 #服務器宿主機操作系統
arch_bits:64 服務器宿主機CUP架構（32位/64位）
multiplexing_api:epoll #redis IO機制
gcc_version:4.8.5  #編譯 redis 時所使用的 GCC 版本
process_id:1508  #服務器進程的 PID
run_id:b4ac0f9086659ce54d87e41d4d2f947e19c28401 #redis 服務器的隨機標識符 （用於 Sentinel 和集羣）
tcp_port:6380  #redis服務監聽端口
uptime_in_seconds:520162 #redis服務啓動以來經過的秒數
uptime_in_days:6 #redis服務啓動以來經過的天數
hz:10  #redis內部調度（進行關閉timeout的客戶端，刪除過期key等等）頻率，程序規定serverCron每秒運行10次
lru_clock:16109450 #自增的時鐘，用於LRU管理,該時鐘100ms(hz=10,因此每1000ms/10=100ms執行一次定時任務)更新一次
executable:/usr/local/bin/redis-server
config_file:/data/redis-6380/redis.conf 配置文件的路徑

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

# Memory
used_memory:426679232 #由 redis 分配器分配的內存總量，以字節（byte）爲單位
used_memory_human:406.91M   #以可讀的格式返回 redis 分配的內存總量（實際是used_memory的格式化）
used_memory_rss:443179008 #從操作系統的角度，返回 redis 已分配的內存總量（俗稱常駐集大小）。這個值和 top 、 ps等命令的輸出一致
used_memory_rss_human:422.65M # redis 的內存消耗峯值(以字節爲單位) 
used_memory_peak:426708912
used_memory_peak_human:406.94M
total_system_memory:16658403328
total_system_memory_human:15.51G
used_memory_lua:37888   # Lua腳本存儲佔用的內存
used_memory_lua_human:37.00K
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:1.04 # used_memory_rss/ used_memory
mem_allocator:jemalloc-4.0.3

# Persistence
loading:0 #服務器是否正在載入持久化文件，0表示沒有，1表示正在加載
rdb_changes_since_last_save:3164272  #離最近一次成功生成rdb文件，寫入命令的個數，即有多少個寫入命令沒有持久化
rdb_bgsave_in_progress:0 #服務器是否正在創建rdb文件，0表示否
rdb_last_save_time:1559093160  #離最近一次成功創建rdb文件的時間戳。當前時間戳 - rdb_last_save_time=多少秒未成功生成rdb文件
rdb_last_bgsave_status:ok  #最近一次rdb持久化是否成功
rdb_last_bgsave_time_sec:-1  #最近一次成功生成rdb文件耗時秒數
rdb_current_bgsave_time_sec:-1 #如果服務器正在創建rdb文件，那麼這個域記錄的就是當前的創建操作已經耗費的秒數
aof_enabled:0 #是否開啓了aof
aof_rewrite_in_progress:0 #標識aof的rewrite操作是否在進行中
aof_rewrite_scheduled:0  #rewrite任務計劃，當客戶端發送bgrewriteaof指令，如果當前rewrite子進程正在執行，那麼將客戶端請求的bgrewriteaof變爲計劃任務，待aof子進程結束後執行rewrite
aof_last_rewrite_time_sec:-1 #最近一次aof rewrite耗費的時長
aof_current_rewrite_time_sec:-1 #如果rewrite操作正在進行，則記錄所使用的時間，單位秒
aof_last_bgrewrite_status:ok #上次bgrewriteaof操作的狀態
aof_last_write_status:ok #上次aof寫入狀態

# Stats
total_connections_received:10   #服務器已經接受的連接請求數量
total_commands_processed:9510792   #redis處理的命令數
instantaneous_ops_per_sec:1   #redis當前的qps，redis內部較實時的每秒執行的命令數
total_net_input_bytes:1104411373   #redis網絡入口流量字節數
total_net_output_bytes:66358938 #redis網絡出口流量字節數
instantaneous_input_kbps:0.04  #redis網絡入口kps
instantaneous_output_kbps:3633.35  #redis網絡出口kps
rejected_connections:0  #拒絕的連接個數，redis連接個數達到maxclients限制，拒絕新連接的個數
sync_full:0  #主從完全同步成功次數
sync_partial_ok:0  #主從部分同步成功次數
sync_partial_err:0  #主從部分同步失敗次數
expired_keys:0   #運行以來過期的key的數量
evicted_keys:0  #運行以來剔除(超過了maxmemory後)的key的數量
keyspace_hits:87  #命中次數
keyspace_misses:17   #沒命中次數
pubsub_channels:0  #當前使用中的頻道數量
pubsub_patterns:0  #當前使用的模式的數量
latest_fork_usec:0   #最近一次fork操作阻塞redis進程的耗時數，單位微秒
migrate_cached_sockets:0   #是否已經緩存了到該地址的連接

# Replication
role:master  #實例的角色，是master or slave
connected_slaves:0  #連接的slave實例個數
master_repl_offset:0 #主從同步偏移量,此值如果和上面的offset相同說明主從一致沒延遲，與master_replid可被用來標識主實例複製流中的位置
repl_backlog_active:0   #複製積壓緩衝區是否開啓
repl_backlog_size:1048576  #複製積壓緩衝大小
repl_backlog_first_byte_offset:0  #複製緩衝區裏偏移量的大小
repl_backlog_histlen:0   #此值等於 master_repl_offset - repl_backlog_first_byte_offset,該值不會超過repl_backlog_size的大小

# CPU
used_cpu_sys:507.00  #將所有redis主進程在覈心態所佔用的CPU時求和累計起來
used_cpu_user:280.48   #將所有redis主進程在用戶態所佔用的CPU時求和累計起來
used_cpu_sys_children:0.00  #將後臺進程在覈心態所佔用的CPU時求和累計起來
used_cpu_user_children:0.00  將後臺進程在用戶態所佔用的CPU時求和累計起來

# Cluster
cluster_enabled:0

# Keyspace
db0:keys=5557407,expires=362,avg_ttl=604780497
db15:keys=1,expires=0,avg_ttl=0