Info Command | Ucode

Appearance

On this page

Info Command ​

When using Redis, you often encounter issues that need diagnosing. Before troubleshooting, it's important to understand Redis's operating status. With the powerful Info command, you can clearly see a series of internal runtime parameters of Redis.

The information displayed by the Info command is extensive, divided into nine major sections, each containing numerous parameters. These nine sections are:

  1. Server: Server environment parameters
  2. Clients: Client-related information
  3. Memory: Memory statistics of the server
  4. Persistence: Persistence information
  5. Stats: General statistics
  6. Replication: Master-slave replication information
  7. CPU: CPU usage
  8. Cluster: Cluster information
  9. KeySpace: Statistics on key-value pairs

The Info command can retrieve all information at once or specific sections.

Get All Information ​

bash
> info
bash
> info memory
bash
> info replication

Given the extensive number of parameters, it would be a huge task to explain each one. Below, I will highlight some key, practical, and commonly used parameters in detail. For readers interested in all parameter details, please refer to the official Redis documentation.

How Many Commands Does Redis Execute Per Second? ​

This information is found in the Stats section and can be viewed with:

bash
> redis-cli info stats | grep ops
  • instantaneous_ops_per_sec: operations per second
instantaneous_ops_per_sec:789

This indicates that the ops are 789, meaning clients send 789 commands to the server every second. In extreme cases, Redis can execute up to 100,000 commands per second, utilizing nearly all CPU resources. If the QPS is too high, consider using the monitor command to quickly observe which keys are being accessed frequently, allowing you to optimize the relevant business processes to reduce I/O. Note that the monitor command can output a massive amount of command text, so it's common to interrupt it with ctrl+c right after execution.

How Many Clients Are Connected to Redis? ​

This information is available in the Clients section and can be viewed with:

bash
> redis-cli info clients
# Clients
connected_clients:124  # Number of connected clients
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0

This information is useful for determining whether there are unexpected connections. If you notice an unusual number, you can use the client list command to list all client connection addresses and identify the source.

Another important parameter to observe is rejected_connections, which indicates the number of client connections refused due to exceeding the maximum connection limit. If this number is large, it means the server's maximum connection limit is set too low and should be adjusted via the maxclients parameter.

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

How Much Memory Is Used by Redis? ​

This information is found in the Memory section and can be viewed with:

bash
> redis-cli info memory | grep used | grep human
used_memory_human:827.46K  # Total memory allocated by the memory allocator (jemalloc)
used_memory_rss_human:3.61M  # Memory usage seen by the OS (as seen by the top command)
used_memory_peak_human:829.41K  # Peak memory consumption of Redis
used_memory_lua_human:37.00K  # Memory used by the Lua scripting engine

If a single Redis instance uses too much memory and there isn't much room for compression in business operations, consider clustering.

What Is the Size of the Replication Backlog Buffer? ​

This information is found in the Replication section and can be viewed with:

bash
> redis-cli info replication | grep backlog
repl_backlog_active:0
repl_backlog_size:1048576  # This is the size of the backlog buffer
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

The size of the replication backlog buffer is crucial, as it significantly impacts master-slave replication efficiency. When a slave temporarily disconnects from the master due to network issues and then reconnects, modification operations that occurred during the downtime are stored in the backlog buffer. This allows the slave to catch up on missed modifications.

The backlog buffer is circular; subsequent commands overwrite earlier content. If a slave is disconnected for too long or the buffer size is too small, the slave may not be able to quickly resume synchronization, as the intermediate modification commands would have been overwritten. In such cases, the slave will have to perform a full synchronization, which consumes significant CPU and network resources.

If multiple slaves are replicating, the backlog buffer is shared and does not grow linearly with the number of slaves. If modification requests are frequent, increase the backlog buffer size to several dozen MB; if usage is low, a few MB may suffice.

bash
> redis-cli info stats | grep sync
sync_full:0
sync_partial_ok:0
sync_partial_err:0  # Number of partial synchronization failures

Check the sync_partial_err variable to decide whether to enlarge the backlog buffer, as it indicates the number of failed partial synchronizations.

Reflection ​

What other important information do you need to check when using Redis? Can you retrieve it directly from the Info command?