Redis info command
info command 命令可以查詢 Redis 運行狀態，是在排查問題中，非常重要的資訊。
Published in
15 min readMar 23, 2022
The INFO command returns information and statistics about the server in a format that is simple to parse by computers and easy to read by humans.
常用命令
Info <option>
> info
■ server：Redis服務器相關的通用信息
■ clients：客戶端連接的相關信息
■ memory：Memory consumption related information - 內存消耗的相關信息
■ persistence：RDB（Redis DataBase）和AOF（Append-Only File）的相關信息
■ stats：expired_keys, evicted_keys, keyspace hits/misses - 通用統計數據
■ replication：Primary/replica replication information - 主/從複製的相關信息
■ cpu：CPU消耗的統計數據
■ commandstats：number of calls, CPU time (total/avg) - Redis命令的統計數據
■ cluster：Redis集群的相關信息
■ keyspace：數據庫相關的統計數據
■ EVERYTHING: Includes all and modulesMemory 內存使用量相關
> memory
# Memory
used_memory:2985614944 : 由 Redis 分配器分配的內存總量，以字節（byte）為單位。Redis will not always free up (return) memory to the OS when keys are removed. It is how most malloc() implementations work in Linux.
used_memory_human:2.78G
used_memory_rss:3066945536 : 從操作系統的角度，返回 Redis 已分配的內存總量（俗稱常駐集大小）。Resident Set Size (RSS) and is the amount of physical memory the operating system has allocated to your Redis instance
used_memory_rss_human:2.86G
used_memory_peak:2988912168
used_memory_peak_human:2.78G
used_memory_lua:37888: LUA 所使用的內存，從節點可以自已載入，所以數值可能不同。
used_memory_lua_human:37.00K
maxmemory:2988441600 - Maxmemory is what customers get for their key. From Ec2 instance memory we publish for EC2 instances, good portion of that memory is reserved for OS and internal purpose. For example, often most of the removed keys were allocated in the same pages as the other keys that still exist.
maxmemory_human:2.78G
maxmemory_policy:volatile-lru
maxmemory is not what it the name implies■ Not limiting Redis RSS memory usage: 跟系統分配的內存空間是不同的。■ Not accounting for memory fragmentation: 不考慮內存破碎率的問題。■ Limits the sum of Redis key storage and client buffers: 包含鍵值 client buffer。■ Does not include replication buffers: 不包含 replication buffer 同步暫存。
mem_fragmentation_ratio = used_memory_rss / used_memory
The fragmentation ratio should be slightly greater than 1 which indicates low memory fragmentation and no memory swapping. A fragmentation ratio above 1.5 indicates significant memory fragmentation since Redis consumes 150% of the physical memory it requested. A fragmentation ratio below 1 tells you that Redis memory allocation exceeds available physical memory and the operating system is swapping. Swapping will cause significant increases in latency.■ mem_fragmentation_ratio < 1 表示Redis內存分配超出了物理內存，操作系統正在進行內存交換，內存交換會引起非常明顯的響應延遲；(常見於備份/同步作業執行時)■ mem_fragmentation_ratio > 1 是合理的；■ mem_fragmentation_ratio > 1.5 說明Redis消耗了實際需要物理內存的150%以上，其中50%是內存碎片率，可能是操作系統或Redis實例中內存管理變差的表現
MEMORY STATE
!!!有關內存使用情況的信息以指標及其各自的數值提供。
> memory state
peak.allocated ：Redis消耗的峰值內存（以字節為單位）（請參閱INFO的 used_memory_peak ）total.allocated ：Redis使用其分配器分配的總字節數（請參閱INFO的 used_memory ）startup.allocated ：Redis在啟動時消耗的初始內存量（以字節為單位）（請參閱INFO的 used_memory_startup ）replication.backlog ：尺寸（參見復制積壓的字節INFO的 repl_backlog_active ）clients.slaves ：所有副本開銷（輸出和查詢緩沖區，連接上下文）的總大小（以字節為單位）clients.normal ：所有客戶端開銷（輸出和查詢緩衝區，連接上下文）的總大小（以字節為單位）aof.buffer ：當前和重寫的AOF緩衝區的總大小（以字節為單位）（分別參見INFO的aof_buffer_length 和 aof_rewrite_buffer_length ）lua.caches ：Lua腳本的緩存開銷的總大小（以字節為單位）
dbXXX ：對於每服務器的數據庫中，主和到期字典的開銷（ overhead.hashtable.main 和 overhead.hashtable.expires ，分別地）報告在字節overhead.total 總和：所有間接費用之和，即： startup.allocated ，replication.backlog ， clients.slaves ， clients.normal ， aof.buffer 以及用於管理Redis密鑰空間的內部數據結構的總開銷（請參閱INFO的used_memory_overhead ）keys.count ：服務器中所有數據庫中存儲的密鑰總數keys.bytes-per-key ：淨內存使用量（ total.allocated 減去
startup.allocated ）和 keys.count 之間的比率dataset.bytes ：在數據集中的字節大小，即 overhead.total 減去total.allocated （參見INFO的 used_memory_dataset ）dataset.percentage ：淨內存使用量中 dataset.bytes 的百分比peak.percentage ： peak.allocated 在總 total.allocated 中所佔的百分比fragmentation ：請參閱INFO的 mem_fragmentation_rationkeyspace 數據庫鍵值數量keyspace: Database related statistics
> keyspace
db0:keys=4,expires=1,avg_ttl=597654
db1:keys=3,expires=0,avg_ttl=0 ← 此時所有key都有效的。
info commandstats 命令執行統計報告
INFO commandstats：number of calls, CPU time (total/avg) - Redis命令的統計數據
> info commandstats
# Commandstats
cmdstat_get:calls=3128747108,usec=7437053264,usec_per_call=2.38
cmdstat_XXX: calls=XXX,usec=XXX,usec_per_call=XXX
■ 第一個XXX是命令的名稱
■ 第二個XXX是命令調用次數
■ 第三個XXX是命令消耗的CPU時間總量（以微秒為單位），第三個XXX是每次調用命令消耗的CPU時間的平均值（以微秒為單位）。收集 “info commandstats”，連續6次，每次間隔10分鐘。
目的:
1) 該命令可以詳細列出每一種指令，所耗用的狀況!! 可以用來分析，當您的數據量變化時，是執行了那些命令。
2) 由於該報告是加總的記錄，所以需要每10分鐘去收取報告，然後用相減的方式得知該10分鐘內，有那些命令被操作過。[+] Redis INFO :
https://redis.io/commands/INFO
> info commandstatsStep1: 建立一個抓取 "> info commandstats" 報告的script。$ ./collect-info-commandstats.sh$ ls collect-info-commandstats.log
collect-info-commandstats.log$ cat collect-info-commandstats.sh
#!/bin/bashsleep=600 #10 mins
count=6 #collect 6 data point.host1="xxx.use1.cache.amazonaws.com"
host2="yyy.use1.cache.amazonaws.com"outputfile="collect-info-commandstats.log"
rm -f $outputfilefor ((i=1;i<=$count;i++))
do
echo `date +%s` >> $outputfile
echo $host1 >> $outputfile
redis-cli -h $host1 info commandstats >> $outputfile
echo "" >> $outputfileecho `date +%s` >> $outputfile
echo $host2 >> $outputfile
redis-cli -h $host2 info commandstats >> $outputfile
echo "" >> $outputfile
sleep $sleep
doneecho "done"Step2: 在 crontab 中，定時每10分鐘執行一次。
$ crontab -l
*/10 * * * * /tmp/collect-info-commandstats.sh 2>&1
Info client: Client連接數量資訊統計
> info client
# Clients
connected_clients:2
cluster_connections:0
maxclients:10000
client_recent_max_input_buffer:32 ←-
client_recent_max_output_buffer:0 ←-
blocked_clients:0
tracking_clients:0
clients_in_timeout_table:0Client Info：客戶端連接的相關信息
> CLIENT INFO
"id=530 addr=127.0.0.1:55720 laddr=127.0.0.1:6379 fd=8 name= age=291982 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=26 qbuf-free=40928 argv-mem=10 obl=0 oll=0 omem=0 tot-mem=61466 events=r cmd=client user=default redir=-1\n"
>> 查目前連線中的 Client IP address
- -
• addr: address/port of the client
• age: total duration of the connection in seconds
• idle: idle time of the connection in seconds
• sub: number of channel subscriptions
• psub: number of pattern matching subscriptions
• qbuf: query buffer length
• obl: output buffer length
• omem: output buffer memory usage
• tot-mem: total memory consumed by this client in its various buffers
- -
• omem : Redis 收到 Redis client 的请求后，回覆的内容会放到内存中，也就是 omem。
• oll: output list length (replies are queued in this list when the buffer is full)" 數量(筆數)
id=11868645 addr=10.1.2.56:23246 fd=94 name= age=4238289 idle=4238259■ 關於此現象的原因，其中一個可能原因是當 client 的連線未成功關閉，因此 redis 仍認為此連接還存在。
例如當 client 端程序未正常的關閉連接、client 端的程序突然 crash、client 端主機異常停機等原因造成這些連接異常中斷。但此時 redis 並未收到連接中斷的請求，因此仍保留了這些連接。■ 針對此現象，可以考慮調整 redis 的 timeout 參數，該參數可以設定 client 端在閒置多久後 redis 會主動關閉此連接。預設值是 0，代表redis不主動關䦭連接。使用 timeout 參數可以避免這些異常中斷的連線仍持續連接在 redis 上。
Q: 為什麼 omem 或 oll 會增加?
■ 正常現象，因為請求一個比較大的回覆，所以接受本來就會相對久一點。
■ 發送很多命令來，Redis 處理完了，但 Redis client 還沒接受完。 (例如使用 pipe line，同時請求多個命令，Redis 都處理完了，但 Redis client 的接收速度可能會跟不上。)
■ Redis client 的底層可能有一些狀況 (網絡抖動、性能受限.. 等)，所以接收回覆的效率相對變差。
Q: 有什麼方法能監控?
■ 定期監控 `client list` 的 omem，但 client list 是一個開銷比較大的命令，當 client 數多時要特別注意。
■ 定期監控 `info client` 中的 client_recent_max_output_buffer 這個命令會記錄最近最大的 omem 值，開銷相對 `client list` 小，但缺點是不會知道是哪個 client。
■ 監控 `info memory` 中的 `used_memory_overhead` 這個值能瞭解到，redis 用來存放數據結構的內存是否有突然的變化。(有變化說明數據結構有變多或變少)
Q: 有什麼方法可以避免?
■ 可以考慮設置 `client-output-buffer-limit-normal-hard-limit` 設定後，超過限制的 Redis client 將被終止，這可以保障其它正常的 client 繼續使用 Redis 。
Top Redis Headaches for Devops — Client Buffers: https://redis.com/blog/top-redis-headaches-for-devops-client-buffers/
client-list: Client 連接資訊
https://redis.io/commands/client-list
redis > client list
id=141285 addr=172.31.15.23:47206 fd=11 name= age=0 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=26 qbuf-free=32742 obl=0 oll=0 omem=0 events=r cmd=client
>> 查目前連線中的 Client IP address
