# ServerRedis_version:2.8.19 ###redis版本号redis_git_sha1:00000000 ###git SHA1redis_git_dirty:0 ###git dir
# Server
Redis_version:2.8.19 ###redis版本号
redis_git_sha1:00000000 ###git SHA1
redis_git_dirty:0 ###git dirty flag
redis_build_id:78796c63e58b72dc
redis_mode:standalone ###redis运行模式
os:linux 2.6.32-431.el6.x86_64 x86_64 ###os版本号
arch_bits:64 ###64位架构
multiplexing_api:epoll ###调用epoll算法
GCc_version:4.4.7 ###gcc版本号
process_id:25899 ###服务器进程PID
run_id:eae356ac1098c13b68f2b00fd7e1c9f93b1c6a2c ###Redis的随机标识符(用于sentinel和集群)
tcp_port:6379 ###Redis监听的端口号
uptime_in_seconds:6419 ###Redis运行时长(s为单位)
uptime_in_days:0 ###Redis运行时长(天为单位)
hz:10
lru_clock:10737922 ###以分钟为单位的自增时钟,用于LRU管理
config_file:/etc/redis/redis.conf ###redis配置文件
# Clients
connected_clients:1 ###已连接客户端的数量( 不包括通过从属服务器连接的客户端) 这个参数也要一定关注, 有飙升和明显下降时都会有问题。 即使不操作
client_longest_output_list:0 ###当前连接的客户端中最长的输出列表
client_biggest_input_buf:0 ###当前连接的客户端中最大的。 输出缓存
blocked_clients:0 ###正在等待阻塞命令( BLPOP、 BRPOP、 BRPOPLPUSH) 的客户端的数量 需监控
# Memory
used_memory:2281560 ###由 Redis 分配器分配的内存总量, 以字节( byte) 为单位
used_memory_human:2.18M ###以更友好的格式输出redis占用的内存
used_memory_rss:2699264 ###从操作系统的角度, 返回 Redis 已分配的内存总量( 俗称常驻集大小) 。 这个值和 top 、 ps 等命令的输出一致, 包含了used_memory和内存碎片。
used_memory_peak:22141272 ### Redis 的内存消耗峰值( 以字节为单位)
used_memory_peak_human:21.12M ###以更友好的格式输出redis峰值内存占用
used_memory_lua:35840 ###LUA引擎所使用的内存大小
mem_fragmentation_ratio:1.18 ### =used_memory_rss /used_memory 这两个参数都包含保存用户k-v数据的内存和redis内部不同数据结构需要占用的内存, 并且RSS指的是包含操作系统给redis实例分配的内存, 这里面还包含不连续分配所带来的开销。 因此在理想情况下, used_memory_rss 的值应该只比 used_memory 稍微高一点儿。 当 rss > used , 且两者的值相差较大时, 表示存在( 内部或外部的) 内存碎片。 内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。 当 used > rss时, 表示 Redis 的部分内存被操作系统换出到交换空间了, 在这种情况下, 操作可能会产生明显的延迟。 可以说这个值大于1.5或者小于1都是有问题的。 当大于1.5的时候需要择机进行服务器重启。 当小于1的时候需要对redis进行数据清理
mem_allocator:jemalloc-3.6.0
redis_version:2.8.19 ###redis版本号
redis_git_sha1:00000000 ###git SHA1
redis_git_dirty:0 ###git dirty flag
redis_build_id:78796c63e58b72dc
redis_mode:standalone ###redis运行模式
os:Linux 2.6.32-431.el6.x86_64 x86_64 ###os版本号
arch_bits:64 ###64位架构
multiplexing_api:epoll ###调用epoll算法
gcc_version:4.4.7 ###gcc版本号
process_id:25899 ###服务器进程PID
run_id:eae356ac1098c13b68f2b00fd7e1c9f93b1c6a2c ###Redis的随机标识符(用于sentinel和集群)
tcp_port:6379 ###Redis监听的端口号
uptime_in_seconds:6419 ###Redis运行时长(s为单位)
uptime_in_days:0 ###Redis运行时长(天为单位)
hz:10
lru_clock:10737922 ###以分钟为单位的自增时钟,用于LRU管理
config_file:/etc/redis/redis.conf ###redis配置文件
# Clients
connected_clients:1 ###已连接客户端的数量( 不包括通过从属服务器连接的客户端) 这个参数也要一定关注, 有飙升和明显下降时都会有问题。 即使不操作
client_longest_output_list:0 ###当前连接的客户端中最长的输出列表
client_biggest_input_buf:0 ###当前连接的客户端中最大的。 输出缓存
blocked_clients:0 ###正在等待阻塞命令( BLPOP、 BRPOP、 BRPOPLPUSH) 的客户端的数量 需监控
# Memory
used_memory:2281560 ###由 Redis 分配器分配的内存总量, 以字节( byte) 为单位
used_memory_human:2.18M ###以更友好的格式输出redis占用的内存
used_memory_rss:2699264 ###从操作系统的角度, 返回 Redis 已分配的内存总量( 俗称常驻集大小) 。 这个值和 top 、 ps 等命令的输出一致, 包含了used_memory和内存碎片。
used_memory_peak:22141272 ### Redis 的内存消耗峰值( 以字节为单位)
used_memory_peak_human:21.12M ###以更友好的格式输出redis峰值内存占用
used_memory_lua:35840 ###LUA引擎所使用的内存大小
mem_fragmentation_ratio:1.18 ### =used_memory_rss /used_memory 这两个参数都包含保存用户k-v数据的内存和redis内部不同数据结构需要占用的内存, 并且RSS指的是包含操作系统给redis实例分配的内存, 这里面还包含不连续分配所带来的开销。 因此在理想情况下, used_memory_rss 的值应该只比 used_memory 稍微高一点儿。 当 rss > used , 且两者的值相差较大时, 表示存在( 内部或外部的) 内存碎片。 内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。 当 used > rss时, 表示 Redis 的部分内存被操作系统换出到交换空间了, 在这种情况下, 操作可能会产生明显的延迟。 可以说这个值大于1.5或者小于1都是有问题的。 当大于1.5的时候需要择机进行服务器重启。 当小于1的时候需要对redis进行数据清理
mem_allocator:jemalloc-3.6.0
--结束END--
本文标题: redis info信息详解A
本文链接: https://lsjlt.com/news/37036.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-10-23
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0