INFO(3valkey)

๐Ÿ“ฆ
version 9.0.6 ยท 2 versions
, in fedora 44

๐Ÿฆ‹ INFO โ€” bestie, it's the server's whole vibe check ๐Ÿฆ‹

Okay so this page comes straight out of the Valkey Command Manual (INFO(3valkey)), and it's literally the command that tells you everything about what your server is going through. Grab a snack, this one's long. ๐Ÿ“


๐ŸŒธ NAME ๐ŸŒธ

info โ€” Returns information and statistics about the server. That's it, that's the whole name section, she's concise. โœจ


๐ŸŽ€ SYNOPSIS ๐ŸŽ€

INFO section [section...]

๐Ÿ’– DESCRIPTION ๐Ÿ’–

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. Like, it's giving bilingual. Fluent in machine and in girl. ๐Ÿ’…

The optional parameter can be used to select a specific section of information:

  • server: General information about the Valkey server
  • clients: Client connections section
  • memory: Memory consumption related information
  • persistence: RDB and AOF related information
  • stats: General statistics
  • replication: primary/replica replication information
  • cpu: CPU consumption statistics
  • commandstats: Valkey command statistics
  • latencystats: Valkey command latency percentile distribution statistics
  • sentinel: Valkey Sentinel section (only applicable to Sentinel instances)
  • cluster: Valkey Cluster section
  • modules: Modules section
  • keyspace: Database related statistics
  • errorstats: Valkey error statistics

It can also take the following values:

  • all: Return all sections (excluding module generated ones)
  • default: Return only the default set of sections
  • everything: Includes all and modules
When no parameter is provided, the default option is assumed. No parameter, no problem, she'll just pick for you. ๐Ÿซถ

And here's what it actually looks like when you run it, no cap:

127.0.0.1:6379> INFO
# SERVER

redis_version:7.2.4
server_name:valkey
valkey_version:255.255.255
redis_git_sha1:b0d5a0f5
redis_git_dirty:1
redis_build_id:1cadaf78f6168f2d
server_mode:standalone
os:Linux 6.1.0-18-amd64 x86_64
arch_bits:64
monotonic_clock:POSIX clock_gettime
multiplexing_api:epoll
atomicvar_api:c11-builtin
gcc_version:12.2.0
process_id:982599
process_supervised:no
run_id:e0abe2248cad0c6d9cb2445d8e6b73448f567f74
tcp_port:6379
server_time_usec:1714701488527373
uptime_in_seconds:94798
uptime_in_days:1
hz:10
configured_hz:10
lru_clock:3425456
executable:/home/viktor/repos/valkey/src/./valkey-server
config_file:
io_threads_active:0
availability_zone:
listener0:name=tcp,bind=*,bind=-::*,port=6379

# CLIENTS

connected_clients:1
cluster_connections:0
maxclients:10000
client_recent_max_input_buffer:20480
client_recent_max_output_buffer:0
blocked_clients:0
tracking_clients:0
pubsub_clients:0
watching_clients:0
clients_in_timeout_table:0
total_watched_keys:0
total_blocking_keys:0
total_blocking_keys_on_nokey:0
paused_reason:none
paused_actions:none
paused_timeout_milliseconds:0

# MEMORY

used_memory:4757704
used_memory_human:4.54M
used_memory_rss:13221888
used_memory_rss_human:12.61M
used_memory_peak:4777616
used_memory_peak_human:4.56M
used_memory_peak_perc:99.58%
used_memory_overhead:989344
used_memory_startup:988648
used_memory_dataset:3768360
used_memory_dataset_perc:99.98%
allocator_allocated:4789624
allocator_active:5042176
allocator_resident:9252864
allocator_muzzy:0
total_system_memory:33280372736
total_system_memory_human:30.99G
used_memory_lua:31744
used_memory_vm_eval:31744
used_memory_lua_human:31.00K
used_memory_scripts_eval:0
number_of_cached_scripts:0
number_of_functions:0
number_of_libraries:0
used_memory_vm_functions:33792
used_memory_vm_total:65536
used_memory_vm_total_human:64.00K
used_memory_functions:184
used_memory_scripts:184
used_memory_scripts_human:184B
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.05
allocator_frag_bytes:252552
allocator_rss_ratio:1.84
allocator_rss_bytes:4210688
rss_overhead_ratio:1.43
rss_overhead_bytes:3969024
mem_fragmentation_ratio:2.80
mem_fragmentation_bytes:8504448
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_total_replication_buffers:0
mem_clients_slaves:0
mem_clients_normal:0
mem_cluster_links:0
mem_aof_buffer:0
mem_allocator:jemalloc-5.3.0
mem_overhead_db_hashtable_rehashing:0
active_defrag_running:0
lazyfree_pending_objects:0
lazyfreed_objects:0

# PERSISTENCE

loading:0
async_loading:0
current_cow_peak:0
current_cow_size:0
current_cow_size_age:0
current_fork_perc:0.00
current_save_keys_processed:0
current_save_keys_total:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1714701488
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_saves:1
rdb_last_cow_size:229376
rdb_last_load_keys_expired:0
rdb_last_load_keys_loaded:0
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_rewrites:0
aof_rewrites_consecutive_failures:0
aof_last_write_status:ok
aof_last_cow_size:0
module_fork_in_progress:0
module_fork_last_cow_size:0

# STATS

total_connections_received:3081
total_commands_processed:3080
instantaneous_ops_per_sec:91
total_net_input_bytes:134722
total_net_output_bytes:686934
total_net_repl_input_bytes:0
total_net_repl_output_bytes:0
instantaneous_input_kbps:4.14
instantaneous_output_kbps:1.55
instantaneous_input_repl_kbps:0.00
instantaneous_output_repl_kbps:0.00
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
expired_stale_perc:0.00
expired_time_cap_reached_count:0
expire_cycle_cpu_milliseconds:1829
evicted_keys:0
evicted_clients:0
evicted_scripts:0
total_eviction_exceeded_time:0
current_eviction_exceeded_time:0
keyspace_hits:877
keyspace_misses:98
pubsub_channels:0
pubsub_patterns:0
pubsubshard_channels:0
latest_fork_usec:832
total_forks:5
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
total_active_defrag_time:0
current_active_defrag_time:0
tracking_total_keys:0
tracking_total_items:0
tracking_total_prefixes:0
unexpected_error_replies:0
total_error_replies:55
dump_payload_sanitizations:0
total_reads_processed:6160
total_writes_processed:3085
io_threaded_reads_processed:0
io_threaded_writes_processed:0
client_query_buffer_limit_disconnections:0
client_output_buffer_limit_disconnections:0
reply_buffer_shrinks:3
reply_buffer_expands:0
eventloop_cycles:710861
eventloop_duration_sum:261482066
eventloop_duration_cmd_sum:4662723
instantaneous_eventloop_cycles_per_sec:283
instantaneous_eventloop_duration_usec:595
acl_access_denied_auth:0
acl_access_denied_cmd:0
acl_access_denied_key:0
acl_access_denied_channel:0

# REPLICATION

role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:488d931b7e08f8e091f674ea64480165971a25f1
master_replid2:0000000000000000000000000000000000000000
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:68.476389
used_cpu_user:219.408941
used_cpu_sys_children:0.003157
used_cpu_user_children:0.008264
used_cpu_sys_main_thread:68.478353
used_cpu_user_main_thread:219.404508

# MODULES

# ERRORSTATS

errorstat_ERR:count=55

# CLUSTER

cluster_enabled:0

# KEYSPACE

๐ŸŒˆ REPLY ๐ŸŒˆ

valkey-protocol(7) Bulk string reply: a map of info fields, one field per line in the form of <field>:<value> where the value can be a comma separated map like <key>=<val>. Also contains section header lines starting with # and blank lines.

Lines can contain a section name (starting with a # character) or a property. All the properties are in the form of field:value terminated by \r\n. Yes bestie, the \r\n is non-negotiable, she's precise like that. ๐Ÿ˜Œ


โšก COMPLEXITY โšก

O(1)


๐Ÿ” ACL CATEGORIES ๐Ÿ”

@dangerous @slow

Not me telling you she's flagged as dangerous and slow โ€” that's literally the ACL categories, not shade. ๐Ÿ‘€

๐Ÿ“œ HISTORY ๐Ÿ“œ

  • Available since: 1.0.0
  • Changed in 7.0.0: Added support for taking multiple section arguments.

๐Ÿงš NOTES ๐Ÿงš

Please note depending on the version of Valkey some of the fields have been added or removed. A robust client application should therefore parse the result of this command by skipping unknown properties, and gracefully handle missing fields. Like, don't be clingy to field names, they come and go. ๐Ÿฆ‹

Here is the description of fields.

Here is the meaning of all fields in the server section:

  • redis_version: Redis OSS version this Valkey server is compatible with
  • valkey_version: Valkey version number (e.g. 7.2.5)
  • valkey_release_stage: The status of the Valkey version: โ€œgaโ€ for generally available versions; โ€œrc1โ€, โ€œrc2โ€, etc. for release candidates; โ€œdevโ€ for development versions. Added in 8.1.
  • redis_git_sha1: Git SHA1
  • redis_git_dirty: Git dirty flag
  • redis_build_id: The build id
  • redis_mode: The serverโ€™s mode (โ€œstandaloneโ€, โ€œsentinelโ€ or โ€œclusterโ€)
  • os: Operating system hosting the Valkey server
  • arch_bits: Architecture (32 or 64 bits)
  • multiplexing_api: Event loop mechanism used by Valkey
  • atomicvar_api โ€” which Atomicvar API the Valkey build is running ๐Ÿ’…
  • gcc_version โ€” the version of the GCC compiler that was used to compile the Valkey server
  • process_id โ€” the PID of the server process
  • process_supervised โ€” what's supervising us bestie, one of "upstart", "systemd", "unknown" or "no"
  • run_id โ€” a random value that identifies this Valkey server (Sentinel and Cluster both use it, iykyk)
  • tcp_port โ€” the TCP/IP listen port
  • server_time_usec โ€” epoch-based system time but make it microsecond precision โœจ
  • uptime_in_seconds โ€” how many seconds it's been since the Valkey server started
  • uptime_in_days โ€” literally the same value, just expressed in days
  • hz โ€” the server's current frequency setting
  • configured_hz โ€” the server's configured frequency setting
  • clients_hz โ€” the current frequency used for client maintenance
  • lru_clock โ€” a clock that increments every minute, for LRU management
  • executable โ€” the path to the server's executable
  • config_file โ€” the path to the config file
  • io_threads_active โ€” a flag telling you whether I/O threads are active
  • availability_zone โ€” tells Valkey your Availability zone if you're running in a cloud environment, see the availability-zone config for more details. Added in Valkey 8.0.
  • shutdown_in_milliseconds โ€” the maximum time remaining for replicas to catch up the replication before the shutdown sequence completes. This field is only present during shutdown, so if you see it, things are happening ๐Ÿ‘€

๐Ÿ’– the clients section ๐Ÿ’–

Here's what every field in the clients section means, bestie:

  • connected_clients โ€” number of client connections (not counting connections from replicas)
  • cluster_connections โ€” an approximation of how many sockets the cluster's bus is using
  • maxclients โ€” the value of the maxclients configuration directive. This is the upper limit for the sum of connected_clients, connected_slaves and cluster_connections.
  • client_recent_max_input_buffer โ€” the biggest input buffer among current client connections
  • client_recent_max_output_buffer โ€” the biggest output buffer among current client connections
  • blocked_clients โ€” number of clients pending on a blocking call (valkey-blpop(7) BLPOP), valkey-brpop(7) BRPOP, valkey-brpoplpush(7) BRPOPLPUSH, valkey-blmove(7) BLMOVE, valkey-bzpopmin(7) BZPOPMIN, valkey-bzpopmax(7) BZPOPMAX)
  • tracking_clients โ€” number of clients being tracked (valkey-client-tracking(7) CLIENT TRACKING)
  • pubsub_clients โ€” number of clients in pubsub mode (valkey-subscribe(7) SUBSCRIBE, valkey-psubscribe(7) PSUBSCRIBE, valkey-ssubscribe(7) SSUBSCRIBE). Added in Valkey 8.0
  • watching_clients โ€” number of clients in watching mode (valkey-watch(7) WATCH). Added in Valkey 8.0
  • clients_in_timeout_table โ€” number of clients in the clients timeout table
  • total_watched_keys โ€” number of watched keys. Added in Valkey 8.0.
  • total_blocking_keys โ€” number of blocking keys.
  • total_blocking_keys_on_nokey โ€” number of blocking keys where one or more clients would like to be unblocked when the key is deleted.
  • paused_reason โ€” the current paused reason of the instance: "client_pause" means it was triggered by valkey-client-pause(7) CLIENT PAUSE, then there's "shutdown_in_progress", "failover_in_progress", and "none" means no clients are paused. Added in Valkey 8.1.
  • paused_actions โ€” the current paused actions of the instance: "all" means all clients are paused, "write" means clients executing write commands are paused, and "none" means no clients are paused. Added in Valkey 8.1.
  • paused_timeout_milliseconds โ€” how much time is left on the paused actions. Added in Valkey 8.1.

๐ŸŒธ the memory section ๐ŸŒธ

And now the memory section, which is lowkey the one everyone scrolls to first ๐Ÿ˜ญ:

  • used_memory โ€” total number of bytes allocated by Valkey using its allocator (either standard libc, jemalloc, or an alternative allocator such as tcmalloc)
  • used_memory_human โ€” human readable representation of the previous value
  • used_memory_rss โ€” number of bytes that Valkey allocated as seen by the operating system (a.k.a resident set size). This is the number reported by tools such as top(1) and ps(1)
  • used_memory_rss_human โ€” human readable representation of the previous value
  • used_memory_peak โ€” peak memory consumed by Valkey (in bytes)
  • used_memory_peak_human โ€” human readable representation of the previous value
  • used_memory_peak_perc โ€” the percentage of used_memory_peak out of used_memory
  • used_memory_overhead โ€” the sum in bytes of all overheads that the server allocated for managing its internal data structures
  • used_memory_startup โ€” initial amount of memory consumed by Valkey at startup, in bytes
  • used_memory_dataset โ€” the size in bytes of the dataset (used_memory_overhead subtracted from used_memory)
  • used_memory_dataset_perc โ€” the percentage of used_memory_dataset out of the net memory usage (used_memory minus used_memory_startup)
  • total_system_memory โ€” the total amount of memory that the Valkey host has
  • total_system_memory_human โ€” human readable representation of the previous value
  • used_memory_lua โ€” number of bytes used by the Lua engine for EVAL scripts. Deprecated, renamed to used_memory_vm_eval
  • used_memory_vm_eval โ€” number of bytes used by the script VM engines for the EVAL framework (not part of used_memory).
  • used_memory_lua_human โ€” human readable representation of the previous value. Deprecated.
  • used_memory_scripts_eval โ€” number of bytes overhead by the EVAL scripts (part of used_memory).
  • number_of_cached_scripts โ€” the number of EVAL scripts cached by the server.
  • number_of_functions โ€” the number of functions.
  • number_of_libraries โ€” the number of libraries.
  • used_memory_vm_functions โ€” number of bytes used by the script VM engines for the Functions framework (not part of used_memory).
  • used_memory_vm_total โ€” used_memory_vm_eval + used_memory_vm_functions (not part of used_memory).
  • used_memory_vm_total_human โ€” human readable representation of the previous value.
  • used_memory_functions โ€” number of bytes overhead by Function scripts (part of used_memory).
  • used_memory_scripts โ€” used_memory_scripts_eval + used_memory_functions (part of used_memory).
  • used_memory_scripts_human โ€” human readable representation of the previous value
  • maxmemory โ€” the value of the maxmemory configuration directive
  • maxmemory_human โ€” human readable representation of the previous value
  • maxmemory_policy โ€” the value of the maxmemory-policy configuration directive
  • mem_fragmentation_ratio โ€” ratio between used_memory_rss and used_memory. Note that this doesn't only include fragmentation, but also other process overheads (see the allocator_* metrics), and also overheads like code, shared libraries, stack, etc.
  • mem_fragmentation_bytes โ€” delta between used_memory_rss and used_memory. Note that when the total fragmentation bytes is low (few megabytes), a high ratio (e.g. 1.5 and above) is not an indication of an issue.
  • allocator_frag_ratio โ€” ratio between allocator_active and allocator_allocated. This is the true (external) fragmentation metric (not mem_fragmentation_ratio).
  • allocator_frag_bytes โ€” delta between allocator_active and allocator_allocated. See note about mem_fragmentation_bytes.
  • allocator_rss_ratio โ€” ratio between allocator_resident and allocator_active. This usually indicates pages that the allocator can and probably will soon release back to the OS.
  • allocator_rss_bytes โ€” delta between allocator_resident and allocator_active
  • rss_overhead_ratio โ€” ratio between used_memory_rss (the process RSS) and allocator_resident. This includes RSS overheads that are not allocator or heap related.
  • rss_overhead_bytes โ€” delta between used_memory_rss (the process RSS) and allocator_resident
  • allocator_allocated โ€” total bytes allocated from the allocator, including internal-fragmentation. Normally the same as used_memory.
  • allocator_active โ€” total bytes in the allocator active pages, this includes external-fragmentation.
  • allocator_resident โ€” total bytes resident (RSS) in the allocator, this includes pages that can be released to the OS (by valkey-memory-purge(7) MEMORY PURGE, or just waiting).
  • allocator_muzzy โ€” total bytes of muzzy memory (RSS) in the allocator. Muzzy memory is memory that has been freed, but not yet fully returned to the operating system. It can be reused immediately when needed or reclaimed by the OS when system pressure increases.
  • mem_not_counted_for_evict โ€” used memory that's not counted for key eviction. This is basically transient replica and AOF buffers.
  • mem_clients_slaves โ€” memory used by replica clients โ€” replica buffers share memory with the replication backlog, so this field can show 0 when replicas don't trigger an increase of memory usage.
  • mem_clients_normal โ€” memory used by normal clients
  • mem_cluster_links โ€” memory used by links to peers on the cluster bus when cluster mode is enabled.
  • mem_aof_buffer โ€” transient memory used for AOF and AOF rewrite buffers
  • mem_replication_backlog โ€” memory used by replication backlog
  • mem_total_replication_buffers โ€” total memory consumed for replication buffers.
  • mem_allocator โ€” memory allocator, chosen at compile time.
  • mem_overhead_db_hashtable_rehashing โ€” temporary memory overhead of database dictionaries currently being rehashed - Added in 8.0.
  • active_defrag_running โ€” when activedefrag is enabled, this indicates whether defragmentation is currently active, and the CPU percentage it intends to utilize.
  • lazyfree_pending_objects โ€” the number of objects waiting to be freed (as a result of calling valkey-unlink(7) UNLINK, or valkey-flushdb(7) FLUSHDB and valkey-flushall(7) FLUSHALL with the ASYNC option)
  • lazyfreed_objects โ€” the number of objects that have been lazy freed.

Ideally, the used_memory_rss value should be only slightly higher than used_memory. When rss >> used, a large difference may mean there is (external) memory fragmentation, which can be evaluated by checking allocator_frag_ratio, allocator_frag_bytes. When used >> rss, it means part of Valkey memory has been swapped off by the operating system: expect some significant latencies. ๐Ÿ˜ญ

Because Valkey does not have control over how its allocations are mapped to memory pages, high used_memory_rss is often the result of a spike in memory usage. ๐Ÿ’€

Okay so when Valkey frees memory, that memory gets handed back to the allocator, and the allocator may or may not give it back to the system. So bestie, there can be a whole discrepancy between the used_memory value and what your OS reports for memory consumption. It might just be because Valkey used and released memory but the system hasn't taken it back yet. The used_memory_peak value is generally the glow-up check for this exact situation. โœจ

If you want extra introspective tea about the server's memory, go peek at the valkey-memory-stats(7) MEMORY STATS command and the valkey-memory-doctor(7) MEMORY DOCTOR. They are literally giving diagnostic main character energy. ๐Ÿฉบ๐Ÿ’…

Here's what every field in the persistence section means:

  • loading โ€” a flag that says if the load of a dump file is on-going.
  • async_loading โ€” rn it's loading the replication data-set asynchronously while still serving old data. This means repl-diskless-load is enabled and set to swapdb.
  • current_cow_peak โ€” the peak size in bytes of copy-on-write memory while a child fork is running.
  • current_cow_size โ€” the size in bytes of copy-on-write memory while a child fork is running.
  • current_cow_size_age โ€” the age, in seconds, of the current_cow_size value.
  • current_fork_perc โ€” the percentage of progress of the current fork process. For AOF and RDB forks it's the percentage of current_save_keys_processed out of current_save_keys_total.
  • current_save_keys_processed โ€” number of keys processed by the current save operation.
  • current_save_keys_total โ€” number of keys at the beginning of the current save operation.
  • rdb_changes_since_last_save โ€” number of changes since the last RDB file save.
  • rdb_bgsave_in_progress โ€” flag indicating a RDB save is on-going, including a diskless replication RDB save.
  • rdb_last_save_time โ€” epoch-based timestamp of last successful RDB file save.
  • rdb_last_bgsave_status โ€” status of the last RDB file save operation.
  • rdb_last_bgsave_time_sec โ€” duration of the last RDB save operation in seconds, including a diskless replication RDB save.
  • rdb_current_bgsave_time_sec โ€” duration of the on-going RDB save operation if any, including a diskless replication RDB save.
  • rdb_last_cow_size โ€” the size in bytes of copy-on-write memory during the last RDB save operation.
  • rdb_last_load_keys_expired โ€” number of volatile keys deleted during the last RDB loading.
  • rdb_last_load_keys_loaded โ€” number of keys loaded during the last RDB loading.
  • aof_enabled โ€” flag indicating AOF logging is activated.
  • aof_rewrite_in_progress โ€” flag indicating a AOF rewrite operation is on-going.
  • aof_rewrite_scheduled โ€” flag indicating an AOF rewrite operation will be scheduled once the on-going RDB save is complete.
  • aof_last_rewrite_time_sec โ€” duration of the last AOF rewrite operation in seconds.
  • aof_current_rewrite_time_sec โ€” duration of the on-going AOF rewrite operation if any.
  • aof_last_bgrewrite_status โ€” status of the last AOF rewrite operation.
  • aof_last_write_status โ€” status of the last write operation to the AOF.
  • aof_last_cow_size โ€” the size in bytes of copy-on-write memory during the last AOF rewrite operation.
  • module_fork_in_progress โ€” flag indicating a module fork is on-going.
  • module_fork_last_cow_size โ€” the size in bytes of copy-on-write memory during the last module fork operation.
  • aof_rewrites โ€” number of AOF rewrites performed since startup.
  • rdb_saves โ€” number of RDB snapshots performed since startup.

rdb_changes_since_last_save refers to the number of operations that produced some kind of changes in the dataset since the last time either valkey-save(7) SAVE or valkey-bgsave(7) BGSAVE was called. No cap, that's the count.

If AOF is activated, these additional fields will be added:

  • aof_current_size โ€” AOF current file size.
  • aof_base_size โ€” AOF file size on latest startup or rewrite.
  • aof_pending_rewrite โ€” flag indicating an AOF rewrite operation will be scheduled once the on-going RDB save is complete.
  • aof_buffer_length โ€” size of the AOF buffer.
  • aof_pending_bio_fsync โ€” number of fsync pending jobs in background I/O queue.
  • aof_delayed_fsync โ€” delayed fsync counter.

If a load operation is on-going, these additional fields will be added:

  • loading_start_time โ€” epoch-based timestamp of the start of the load operation.
  • loading_total_bytes โ€” total file size.
  • loading_rdb_used_mem โ€” the memory usage of the server that had generated the RDB file at the time of the file's creation.
  • loading_loaded_bytes โ€” number of bytes already loaded.
  • loading_loaded_perc โ€” same value expressed as a percentage.
  • loading_eta_seconds โ€” ETA in seconds for the load to be complete.

Here's the meaning of all fields in the stats section:

  • total_connections_received โ€” total number of connections accepted by the server.
  • total_commands_processed โ€” total number of commands processed by the server.
  • instantaneous_ops_per_sec โ€” number of commands processed per second.
  • total_net_input_bytes โ€” the total number of bytes read from the network.
  • total_net_output_bytes โ€” the total number of bytes written to the network.
  • total_net_repl_input_bytes โ€” the total number of bytes read from the network for replication purposes.
  • total_net_repl_output_bytes โ€” the total number of bytes written to the network for replication purposes.
  • instantaneous_input_kbps โ€” the network's read rate per second in KB/sec.
  • instantaneous_output_kbps โ€” the network's write rate per second in KB/sec.
  • instantaneous_input_repl_kbps โ€” the network's read rate per second in KB/sec for replication purposes.
  • instantaneous_output_repl_kbps โ€” the network's write rate per second in KB/sec for replication purposes.
  • rejected_connections โ€” number of connections rejected because of maxclients limit.
  • sync_full โ€” the number of full resyncs with replicas.
  • sync_partial_ok โ€” the number of accepted partial resync requests.
  • sync_partial_err โ€” the number of denied partial resync requests.
  • expired_keys โ€” total number of key expiration events.
  • expired_stale_perc โ€” the percentage of keys probably expired.
  • expired_time_cap_reached_count โ€” the count of times that active expiry cycles have stopped early.
  • expire_cycle_cpu_milliseconds โ€” the cumulative amount of time spent on active expiry cycles.
  • evicted_keys โ€” number of evicted keys due to maxmemory limit.
  • evicted_clients โ€” number of evicted clients due to maxmemory-clients limit.
  • evicted_scripts โ€” number of evicted EVAL scripts due to LRU policy, see valkey-eval(7) EVAL for more details. Added in Valkey 8.0.
  • total_eviction_exceeded_time โ€” total time used_memory was greater than maxmemory since server startup, in milliseconds.
  • current_eviction_exceeded_time โ€” the time passed since used_memory last rose above maxmemory, in milliseconds.
  • keyspace_hits โ€” number of successful lookup of keys in the main dictionary.
  • keyspace_misses โ€” number of failed lookup of keys in the main dictionary.
  • pubsub_channels โ€” global number of pub/sub channels with client subscriptions.
  • pubsub_patterns โ€” global number of pub/sub pattern with client subscriptions.
  • pubsubshard_channels โ€” global number of pub/sub shard channels with client subscriptions.
  • latest_fork_usec โ€” duration of the latest fork operation in microseconds.
  • total_forks โ€” total number of fork operations since the server start.
  • migrate_cached_sockets โ€” the number of sockets open for MIGRATE purposes.
  • slave_expires_tracked_keys โ€” the number of keys tracked for expiry purposes (applicable only to writable replicas).
  • active_defrag_hits โ€” number of value reallocations performed by active the defragmentation process.
  • active_defrag_misses โ€” number of aborted value reallocations started by the active defragmentation process.
  • active_defrag_key_hits โ€” number of keys that were actively defragmented.
  • active_defrag_key_misses โ€” number of keys that were skipped by the active defragmentation process.
  • total_active_defrag_time โ€” total time memory fragmentation was over the limit, in milliseconds.
  • current_active_defrag_time โ€” the time passed since memory fragmentation last was over the limit, in milliseconds.
  • tracking_total_keys โ€” number of keys being tracked by the server.
  • tracking_total_items โ€” number of items, that is the sum of clients number for each key, that are being tracked.
  • tracking_total_prefixes โ€” number of tracked prefixes in server's prefix table (only applicable for broadcast mode).
  • unexpected_error_replies โ€” number of unexpected error replies, that are types of errors from an AOF load or replication.
  • total_error_replies โ€” total number of issued error replies, that is the sum of rejected commands (errors prior command execution) and failed commands (errors within the command execution).
  • dump_payload_sanitizations โ€” total number of dump payload deep integrity validations (see sanitize-dump-payload config).
  • total_reads_processed โ€” total number of read events processed.
  • total_writes_processed โ€” total number of write events processed.
  • io_threaded_reads_processed โ€” number of read events processed by the I/O threads.
  • io_threaded_writes_processed โ€” number of write events processed by the I/O threads.
  • io_threaded_total_prefetch_batches โ€” indicate how many prefetch batches were executed in order to prefetch keys before executing commands.
  • io_threaded_total_prefetch_entries โ€” the total number of dict entries that were prefetched. Each batch can contain multiple entries, the ratio entries/batches indicates how many entries were prefetched per batch on average.
  • io_threaded_poll_processed โ€” total poll system calls performed by the I/O threads.
  • io_threaded_freed_objects โ€” the total number of objects freed by the I/O threads.
  • client_query_buffer_limit_disconnections โ€” total number of disconnections due to client reaching query buffer limit.
  • client_output_buffer_limit_disconnections โ€” total number of disconnections due to client reaching output buffer limit.
  • reply_buffer_shrinks โ€” total number of output buffer shrinks.
  • reply_buffer_expands โ€” total number of output buffer expands.
  • eventloop_cycles โ€” total number of eventloop cycles.
  • eventloop_duration_sum โ€” total time spent in the eventloop in microseconds (including I/O and command processing).
  • eventloop_duration_cmd_sum โ€” total time spent on executing commands in microseconds.
  • instantaneous_eventloop_cycles_per_sec โ€” number of eventloop cycles per second.
  • instantaneous_eventloop_duration_usec โ€” the average time we spend in a single eventloop cycle, measured in microseconds โฑ๏ธ
  • acl_access_denied_auth โ€” how many authentication attempts flopped ๐Ÿ’€
  • acl_access_denied_cmd โ€” how many commands got rejected because access to the command was denied ๐Ÿšซ
  • acl_access_denied_key โ€” how many commands got rejected because access to a key was denied ๐Ÿ”‘
  • acl_access_denied_channel โ€” how many commands got rejected because access to a channel was denied ๐Ÿ“ก

๐Ÿ’– the replication section ๐Ÿ’–

Here's what every single field in the replication section actually means, bestie:

  • role โ€” the value is โ€œmasterโ€ if this instance is a replica of no one, or โ€œslaveโ€ if the instance is a replica of some primary instance. And yes, note that a replica can itself be the primary of another replica (that's chained replication, iconic behavior) ๐Ÿ”—
  • master_failover_state โ€” the state of an ongoing failover, if there's one happening rn ๐Ÿ‘€
  • master_replid โ€” the replication ID of the Valkey server ๐Ÿ†”
  • master_replid2 โ€” the secondary replication ID, used for PSYNC after a failover ๐Ÿ”
  • master_repl_offset โ€” the server's current replication offset ๐Ÿ“
  • second_repl_offset โ€” the offset up to which replication IDs are accepted ๐Ÿ“
  • repl_backlog_active โ€” flag saying whether the replication backlog is active โœ…
  • repl_backlog_size โ€” total size, in bytes, of the replication backlog buffer ๐Ÿ“ฆ
  • repl_backlog_first_byte_offset โ€” the primary offset of the replication backlog buffer ๐Ÿฅ‡
  • repl_backlog_histlen โ€” size in bytes of the data sitting in the replication backlog buffer ๐Ÿ’พ

If the instance is a replica, you also get these extra fields, bestie:

  • master_host โ€” host or IP address of the primary ๐Ÿ 
  • master_port โ€” primary listening TCP port ๐Ÿ”Œ
  • master_link_status โ€” status of the link (up/down) ๐Ÿ“ถ
  • master_last_io_seconds_ago โ€” number of seconds since the last interaction with the primary ๐Ÿ•ฐ๏ธ
  • master_sync_in_progress โ€” indicates the primary is syncing to the replica ๐Ÿ”„
  • slave_read_repl_offset โ€” the read replication offset of the replica instance ๐Ÿ“–
  • slave_repl_offset โ€” the replication offset of the replica instance ๐Ÿงญ
  • slave_priority โ€” the priority of the instance as a candidate for failover ๐Ÿ†
  • slave_read_only โ€” flag indicating whether the replica is read-only ๐Ÿ”’
  • replica_announced โ€” flag indicating whether the replica is announced by Sentinel ๐Ÿ“ข

If a SYNC operation is on-going, you get these extra fields too:

  • master_sync_total_bytes โ€” total number of bytes that need to be transferred. This may be 0 when the size is unknown (for example, when the repl-diskless-sync configuration directive is used) ๐Ÿคท
  • master_sync_read_bytes โ€” number of bytes already transferred โœ…
  • master_sync_left_bytes โ€” number of bytes left before syncing is complete (may be negative when master_sync_total_bytes is 0) ๐Ÿ˜ฌ
  • master_sync_perc โ€” the percentage master_sync_read_bytes from master_sync_total_bytes, or an approximation that uses loading_rdb_used_mem when master_sync_total_bytes is 0 ๐Ÿ“Š
  • master_sync_last_io_seconds_ago โ€” number of seconds since the last transfer I/O during a SYNC operation โŒ›

If the link between primary and replica is down, there's one more field for you:

  • master_link_down_since_seconds โ€” number of seconds since the link went down ๐Ÿ’”

And this field is always provided, no matter what:

  • connected_slaves โ€” number of connected replicas ๐Ÿซ‚

If the server is configured with the min-replicas-to-write directive, you get one extra field:

  • min_slaves_good_slaves โ€” number of replicas currently considered good ๐Ÿ‘ผ

And for each replica, this line gets added:

  • slaveXXX โ€” id, IP address, port, state, offset, lag ๐Ÿงพ

๐Ÿ–ฅ๏ธ the cpu section ๐Ÿ–ฅ๏ธ

Here's the meaning of every field in the cpu section:

  • used_cpu_sys โ€” system CPU consumed by the Valkey server, which is the sum of system CPU consumed by all threads of the server process (main thread and background threads) ๐Ÿงฎ
  • used_cpu_user โ€” user CPU consumed by the Valkey server, which is the sum of user CPU consumed by all threads of the server process (main thread and background threads) ๐Ÿงฎ
  • used_cpu_sys_children โ€” system CPU consumed by the background processes ๐Ÿ‘ถ
  • used_cpu_user_children โ€” user CPU consumed by the background processes ๐Ÿ‘ถ
  • used_cpu_sys_main_thread โ€” system CPU consumed by the Valkey server main thread ๐Ÿงต
  • used_cpu_user_main_thread โ€” user CPU consumed by the Valkey server main thread ๐Ÿงต

๐Ÿ“ˆ the commandstats section ๐Ÿ“ˆ

The commandstats section hands you statistics based on the command type, and it includes the number of calls that reached command execution (not rejected), the total CPU time consumed by these commands, the average CPU consumed per command execution, the number of rejected calls (errors prior to command execution), and the number of failed calls (errors within the command execution). So much data, we love her ๐Ÿ’…

For each command type, this line gets added:

  • cmdstat_XXX โ€” calls=XXX,usec=XXX,usec_per_call=XXX,rejected_calls=XXX,failed_calls=XXX

๐Ÿฆ‹ the latencystats section ๐Ÿฆ‹

The latencystats section gives you latency percentile distribution statistics, based on the command type โœจ

By default, the exported latency percentiles are the p50, p99, and p999. If you need to change the exported percentiles, use CONFIG SET latency-tracking-info-percentiles "50.0 99.0 99.9".

This section requires the extended latency monitoring feature to be enabled (and by default it's enabled, so you're probably fine). If you need to enable it, use valkey-config-set(7) CONFIG SET latency-tracking yes.

For each command type, this line gets added:

  • latency_percentiles_usec_XXX โ€” p<percentile 1>=<percentile 1 value>,p<percentile 2>=<percentile 2 value>,...

๐Ÿšจ the errorstats section ๐Ÿšจ

The errorstats section enables keeping track of the different errors that occurred within Valkey, based upon the reply error prefix (the first word after the โ€œ-โ€, up to the first space. Example: ERR).

For each error type, this line gets added:

  • errorstat_XXX โ€” count=XXX

๐Ÿ‘‘ the sentinel section ๐Ÿ‘‘

The sentinel section is only available in Valkey Sentinel instances. It's made up of these fields:

  • sentinel_masters โ€” number of Valkey primaries monitored by this Sentinel instance ๐Ÿ‘€
  • sentinel_tilt โ€” a value of 1 means this sentinel is in TILT mode ๐ŸŒ€
  • sentinel_tilt_since_seconds โ€” duration in seconds of the current TILT, or -1 if it's not TILTed โฒ๏ธ
  • sentinel_total_tilt โ€” the number of times this sentinel has been in TILT mode since running. Added in 9.0 ๐Ÿ†•
  • sentinel_running_scripts โ€” the number of scripts this Sentinel is currently executing ๐Ÿ“œ
  • sentinel_scripts_queue_length โ€” the length of the queue of user scripts that are pending execution โณ
  • sentinel_simulate_failure_flags โ€” flags for the SENTINEL SIMULATE-FAILURE command ๐Ÿšฉ

๐ŸŒˆ the cluster section ๐ŸŒˆ

The cluster section currently only contains one unique field:

  • cluster_enabled โ€” indicates whether Valkey cluster is enabled โœ…

๐Ÿงฉ the modules section ๐Ÿงฉ

The modules section contains additional information about loaded modules, if the modules actually provide it. The field part of properties lines in this section is always prefixed with the module's name ๐Ÿท๏ธ

๐Ÿ—„๏ธ the keyspace section ๐Ÿ—„๏ธ

The keyspace section gives you statistics on the main dictionary of each database. Those statistics are the number of keys, and the number of keys with an expiration ๐Ÿ—๏ธ

For each database, this line gets added:

  • dbXXX โ€” keys=XXX,expires=XXX

๐Ÿ› the debug section ๐Ÿ›

The debug section contains experimental metrics, which might change or get removed in future versions. Heads up: it won't be included when INFO or INFO ALL are called, and it's returned only when INFO DEBUG is used ๐Ÿ‘€

  • eventloop_duration_aof_sum โ€” total time spent on flushing AOF in eventloop, in microseconds ๐Ÿงพ
  • eventloop_duration_cron_sum โ€” total time consumption of cron in microseconds (including serverCron and beforeSleep, but excluding IO and AOF flushing) โฐ
  • eventloop_duration_max โ€” the maximal time spent in a single eventloop cycle, in microseconds ๐Ÿฅ‡
  • eventloop_cmd_per_cycle_max โ€” the maximal number of commands processed in a single eventloop cycle ๐Ÿš€

A note about the word slave used in this man page: if not for backward compatibility, the Valkey project no longer uses the words โ€œmasterโ€ and โ€œslaveโ€. Unfortunately in the given commands these words are part of the protocol, so we'll be able to remove such occurrences only when this API will be naturally deprecated. So yeah, it's giving legacy, but we move ๐Ÿซ 

Modules generated sections: starting with Valkey 6, modules can inject their info into the INFO command, and these are excluded by default even when the all argument is provided (it will include a list of loaded modules but not their generated info fields). To get these you must use either the modules argument or everything. ๐Ÿงš


๐ŸŒŸ SEE ALSO ๐ŸŒŸ

acl(3valkey), acl-cat(3valkey), acl-deluser(3valkey), acl-dryrun(3valkey), acl-genpass(3valkey), acl-getuser(3valkey), acl-help(3valkey), acl-list(3valkey), acl-load(3valkey), acl-log(3valkey), acl-save(3valkey), acl-setuser(3valkey), acl-users(3valkey), acl-whoami(3valkey), bgrewriteaof(3valkey), bgsave(3valkey), command(3valkey), command-count(3valkey), command-docs(3valkey), command-getkeys(3valkey), command-getkeysandflags(3valkey), command-help(3valkey), command-info(3valkey), command-list(3valkey), commandlog(3valkey), commandlog-get(3valkey), commandlog-help(3valkey), commandlog-len(3valkey), commandlog-reset(3valkey), config(3valkey), config-get(3valkey), config-help(3valkey), config-resetstat(3valkey), config-rewrite(3valkey), config-set(3valkey), dbsize(3valkey), debug(3valkey), failover(3valkey), flushall(3valkey), flushdb(3valkey), lastsave(3valkey), latency(3valkey), latency-doctor(3valkey), latency-graph(3valkey), latency-help(3valkey), latency-histogram(3valkey), latency-history(3valkey), latency-latest(3valkey), latency-reset(3valkey), lolwut(3valkey), memory(3valkey), memory-doctor(3valkey), memory-help(3valkey), memory-malloc-stats(3valkey), memory-purge(3valkey), memory-stats(3valkey), memory-usage(3valkey), module(3valkey), module-help(3valkey), module-list(3valkey), module-load(3valkey), module-loadex(3valkey), module-unload(3valkey), monitor(3valkey), psync(3valkey), replconf(3valkey), replicaof(3valkey), restore-asking(3valkey), role(3valkey), save(3valkey), shutdown(3valkey), slowlog(3valkey), slowlog-get(3valkey), slowlog-help(3valkey), slowlog-len(3valkey), slowlog-reset(3valkey), swapdb(3valkey), sync(3valkey), time(3valkey)


That's the whole page, bestie โ€” you made it to the end and honestly? ate and left no crumbs ๐Ÿ‘‘ This version is from 9.0.0 and it's dated 2025-10-21. Go forth and INFO responsibly, mwah ๐Ÿ’–

๐Ÿ“ฆ where this page comes from