在使用 Redis 時，時常會遇到很多問題需要診斷，在診斷之前需要了解 Redis 的運行狀態(tài)，通過強大的 Info 指令，你可以清晰地知道 Redis 內(nèi)部一系列運行參數(shù)。

Info 指令顯示的信息非常繁多，分為 9 大塊，每個塊都有非常多的參數(shù)，這 9 個塊分別是:

1、Server 服務(wù)器運行的環(huán)境參數(shù)

2、Clients 客戶端相關(guān)信息

3、Memory 服務(wù)器運行內(nèi)存統(tǒng)計數(shù)據(jù)

4、Persistence 持久化信息

5、Stats 通用統(tǒng)計數(shù)據(jù)

6、Replication 主從復(fù)制相關(guān)信息

7、CPU CPU 使用情況

8、Cluster 集群信息

9、KeySpace 鍵值對統(tǒng)計數(shù)量信息

Info 可以一次性獲取所有的信息，也可以按塊取信息。

# 獲取所有信息 > info # 獲取內(nèi)存相關(guān)信息 > info memory # 獲取復(fù)制相關(guān)信息 > info replication

Redis 每秒執(zhí)行多少次指令?

這個信息在 Stats 塊里，可以通過 info stats 看到。

# ops_per_sec: operations per second，也就是每秒操作數(shù) > redis-cli info stats |grep ops instantaneous_ops_per_sec:789

以上，表示 ops 是 789，也就是所有客戶端每秒會發(fā)送 789 條指令到服務(wù)器執(zhí)行。極限情況下，Redis 可以每秒執(zhí)行 10w 次指令，CPU 幾乎完全榨干。如果 qps 過高，可以考慮通過 monitor 指令快速觀察一下究竟是哪些 key 訪問比較頻繁，從而在相應(yīng)的業(yè)務(wù)上進(jìn)行優(yōu)化，以減少 IO 次數(shù)。monitor 指令會瞬間吐出來巨量的指令文本，所以一般在執(zhí)行monitor 后立即 ctrl+c 中斷輸出。

> redis-cli monitor

這個信息在 Clients 塊里，可以通過 info clients 看到。

> redis-cli info clients # Clients connected_clients:124 # 這個就是正在連接的客戶端數(shù)量 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0

這個信息也是比較有用的，通過觀察這個數(shù)量可以確定是否存在意料之外的連接。如果發(fā)現(xiàn)這個數(shù)量不對勁，接著就可以使用 client list 指令列出所有的客戶端鏈接地址來確定源 頭。

關(guān)于客戶端的數(shù)量還有個重要的參數(shù)需要觀察，那就是 rejected_connections，它表示因為超出最大連接數(shù)限制而被拒絕的客戶端連接次數(shù)，如果這個數(shù)字很大，意味著服務(wù)器的最大連接數(shù)設(shè)置的過低需要調(diào)整 maxclients 參數(shù)。

> redis-cli info stats |grep reject rejected_connections:0

Redis 內(nèi)存占用多大 ?

這個信息在 Memory 塊里，可以通過 info memory 看到。

> redis-cli info memory | grep used | grep human used_memory_human:827.46K # 內(nèi)存分配器 (jemalloc) 從操作系統(tǒng)分配的內(nèi)存總量 used_memory_rss_human:3.61M # 操作系統(tǒng)看到的內(nèi)存占用 ,top 命令看到的內(nèi)存 used_memory_peak_human:829.41K # Redis 內(nèi)存消耗的峰值 used_memory_lua_human:37.00K # lua 腳本引擎占用的內(nèi)存大小

如果單個 Redis 內(nèi)存占用過大，并且在業(yè)務(wù)上沒有太多壓縮的空間的話，可以考慮集群化了。

復(fù)制積壓緩沖區(qū)多大?

這個信息在 Replication 塊里，可以通過 info replication 看到。

> redis-cli info replication |grep backlog repl_backlog_active:0 repl_backlog_size:1048576 # 這個就是積壓緩沖區(qū)大小 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0

復(fù)制積壓緩沖區(qū)大小非常重要，它嚴(yán)重影響到主從復(fù)制的效率。當(dāng)從庫因為網(wǎng)絡(luò)原因臨 時斷開了主庫的復(fù)制，然后網(wǎng)絡(luò)恢復(fù)了，又重新連上的時候，這段斷開的時間內(nèi)發(fā)生在 master 上的修改操作指令都會放在積壓緩沖區(qū)中，這樣從庫可以通過積壓緩沖區(qū)恢復(fù)中斷的 主從同步過程。

積壓緩沖區(qū)是環(huán)形的，后來的指令會覆蓋掉前面的內(nèi)容。如果從庫斷開的時間過長，或 者緩沖區(qū)的大小設(shè)置的太小，都會導(dǎo)致從庫無法快速恢復(fù)中斷的主從同步過程，因為中間的修改指令被覆蓋掉了。這時候從庫就會進(jìn)行全量同步模式，非常耗費 CPU 和網(wǎng)絡(luò)資源。 如果有多個從庫復(fù)制，積壓緩沖區(qū)是共享的，它不會因為從庫過多而線性增長。如果實例的修改指令請求很頻繁，那就把積壓緩沖區(qū)調(diào)大一些，幾十個 M 大小差不多了，如果很 閑，那就設(shè)置為幾個 M。

> redis-cli info stats | grep sync sync_full:0 sync_partial_ok:0 sync_partial_err:0 # 半同步失敗次數(shù)

通過查看 sync_partial_err 變量的次數(shù)來決定是否需要擴大積壓緩沖區(qū)，它表示主從半同步復(fù)制失敗的次數(shù)。

總結(jié)

以上是生活随笔為你收集整理的redis的info指令详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。