Redis Info 命令

Redis Info 命令以一種易於理解和閱讀的格式，返回關於 Redis 服務器的各種信息和統計數值。

通過給定可選的參數 section ，可以讓命令只返回某一部分的信息：

• server : 一般 Redis 服務器信息，包含以下域：

  • redis_version : Redis 服務器版本
  • redis_git_sha1 : Git SHA1
  • redis_git_dirty : Git dirty flag
  • os : Redis 服務器的宿主操作系統
  • arch_bits : 架構（32 或 64 位）
  • multiplexing_api : Redis 所使用的事件處理機制
  • gcc_version : 編譯 Redis 時所使用的 GCC 版本
  • process_id : 服務器進程的 PID
  • run_id : Redis 服務器的隨機標識符（用於 Sentinel 和集群）
  • tcp_port : TCP/IP 監聽端口
  • uptime_in_seconds : 自 Redis 服務器啟動以來，經過的秒數
  • uptime_in_days : 自 Redis 服務器啟動以來，經過的天數
  • lru_clock : 以分鍾為單位進行自增的時鍾，用於 LRU 管理

• clients : 已連接客戶端信息，包含以下域：

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

• memory : 內存信息，包含以下域：

  • used_memory : 由 Redis 分配器分配的內存總量，以字節（byte）為單位
  • used_memory_human : 以人類可讀的格式返回 Redis 分配的內存總量
  • used_memory_rss : 從操作系統的角度，返回 Redis 已分配的內存總量（俗稱常駐集大小）。這個值和 top 、 ps 等命令的輸出一致。
  • used_memory_peak : Redis 的內存消耗峰值（以字節為單位）
  • used_memory_peak_human : 以人類可讀的格式返回 Redis 的內存消耗峰值
  • used_memory_lua : Lua 引擎所使用的內存大小（以字節為單位）
  • mem_fragmentation_ratio : used_memory_rss 和 used_memory 之間的比率
  • mem_allocator : 在編譯時指定的， Redis 所使用的內存分配器。可以是 libc 、 jemalloc 或者 tcmalloc 。

  在理想情況下， used_memory_rss 的值應該只比 used_memory 稍微高一點兒。

  當 rss > used ，且兩者的值相差較大時，表示存在（內部或外部的）內存碎片。

  內存碎片的比率可以通過 mem_fragmentation_ratio 的值看出。

  當 used > rss 時，表示 Redis 的部分內存被操作系統換出到交換空間了，在這種情況下，操作可能會產生明顯的延遲。

  當 Redis 釋放內存時，分配器可能會，也可能不會，將內存返還給操作系統。

  如果 Redis 釋放了內存，卻沒有將內存返還給操作系統，那么 used_memory 的值可能和操作系統顯示的 Redis 內存占用並不一致。

  查看 used_memory_peak 的值可以驗證這種情況是否發生。

• persistence : RDB 和 AOF 的相關信息

• stats : 一般統計信息

• replication : 主/從復制信息

• cpu : CPU 計算量統計信息

• commandstats : Redis 命令統計信息

• cluster : Redis 集群信息

• keyspace : 數據庫相關的統計信息

# Server
redis_version:5.0.8
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:f5de7c59791f2d0a
redis_mode:standalone
os:Linux 3.10.0-1062.18.1.el7.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:8.3.0
process_id:1
run_id:0af71da428854489e825ed709a3abe82af43c60d
tcp_port:6379
uptime_in_seconds:558729
uptime_in_days:6
hz:10
configured_hz:10
lru_clock:10464552
executable:/data/redis-server
config_file:

# Clients
connected_clients:3
client_recent_max_input_buffer:2
client_recent_max_output_buffer:0
blocked_clients:0

# Memory
used_memory:898560
used_memory_human:877.50K
used_memory_rss:12513280
used_memory_rss_human:11.93M
used_memory_peak:4998384
used_memory_peak_human:4.77M
used_memory_peak_perc:17.98%
used_memory_overhead:877034
used_memory_startup:791264
used_memory_dataset:21526
used_memory_dataset_perc:20.06%
allocator_allocated:1158176
allocator_active:1409024
allocator_resident:8511488
total_system_memory:3973369856
total_system_memory_human:3.70G
used_memory_lua:66560
used_memory_lua_human:65.00K
used_memory_scripts:2160
used_memory_scripts_human:2.11K
number_of_cached_scripts:6
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.22
allocator_frag_bytes:250848
allocator_rss_ratio:6.04
allocator_rss_bytes:7102464
rss_overhead_ratio:1.47
rss_overhead_bytes:4001792
mem_fragmentation_ratio:14.61
mem_fragmentation_bytes:11656720
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:83538
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0

# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1587046539
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:6402048
aof_enabled:0
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
aof_last_cow_size:0

# Stats
total_connections_received:88
total_commands_processed:238
instantaneous_ops_per_sec:0
total_net_input_bytes:67596
total_net_output_bytes:148055
instantaneous_input_kbps:0.00
instantaneous_output_kbps:0.00
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:3
expired_stale_perc:0.00
expired_time_cap_reached_count:0
evicted_keys:0
keyspace_hits:21
keyspace_misses:39
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:1220
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0

# Replication
role:master
connected_slaves:0
master_replid:f3f5c1ebf085e9a74a401b88efdb18bd89848233
master_replid2:91f3e9b0b11bc5f4083e846a1399174e86933f92
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

# CPU
used_cpu_sys:869.539401
used_cpu_user:895.500259
used_cpu_sys_children:0.053327
used_cpu_user_children:0.365536

# Cluster
cluster_enabled:0

# Keyspace
db0:keys=1,expires=0,avg_ttl=0
127.0.0.1:6379>

 

當然也可以獲取單個的信息

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
master_replid:f3f5c1ebf085e9a74a401b88efdb18bd89848233
master_replid2:91f3e9b0b11bc5f4083e846a1399174e86933f92
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
127.0.0.1:6379>

Redis 每秒執行多少次指令

root@d4cad7fb69c2:/data# redis-cli info stats |grep ops
instantaneous_ops_per_sec:789
root@d4cad7fb69c2:/data#

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

root@d4cad7fb69c2:/data#  redis-cli monitor
OK
^Z
[1]+  Stopped                 redis-cli monitor
root@d4cad7fb69c2:/data#

Redis 連接了多少客戶端 ？
這個信息在 Clients 塊里，可以通過 info clients 看到。

root@d4cad7fb69c2:/data# redis-cli info clients
# Clients
connected_clients:4
client_recent_max_input_buffer:2
client_recent_max_output_buffer:0
blocked_clients:0
root@d4cad7fb69c2:/data#

 

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

關於客戶端的數量還有個重要的參數需要觀察，那就是 rejected_connections，它表示因
為超出最大連接數限制而被拒絕的客戶端連接次數，如果這個數字很大，意味着服務器的最
大連接數設置的過低需要調整 maxclients 參數。

root@d4cad7fb69c2:/data# redis-cli info stats |grep reject
rejected_connections:0
root@d4cad7fb69c2:/data#

Redis 內存占用多大 ?

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

root@d4cad7fb69c2:/data# redis-cli info memory | grep used | grep human
used_memory_human:897.02K  # 內存分配器 (jemalloc) 從操作系統分配的內存總量
used_memory_rss_human:11.93M  # 操作系統看到的內存占用 ,top 命令看到的內存
used_memory_peak_human:4.77M  # Redis 內存消耗的峰值
used_memory_lua_human:65.00K  # lua 腳本引擎占用的內存大小
used_memory_scripts_human:2.11K
root@d4cad7fb69c2:/data#

如果單個 Redis 內存占用過大，並且在業務上沒有太多壓縮的空間的話，可以考慮集群化了。

復制積壓緩沖區多大?

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

root@d4cad7fb69c2:/data# redis-cli info replication |grep backlog
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
root@d4cad7fb69c2:/data#

復制積壓緩沖區大小非常重要，它嚴重影響到主從復制的效率。當從庫因為網絡原因臨時斷開了主庫的復制，然后網絡恢復了，又重新連上的時候，這段斷開的時間內發生在
master 上的修改操作指令都會放在積壓緩沖區中，這樣從庫可以通過積壓緩沖區恢復中斷的主從同步過程。

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

root@d4cad7fb69c2:/data# redis-cli info stats | grep sync
sync_full:0
sync_partial_ok:0
sync_partial_err:0  # 半同步失敗次數

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