监控指标

• 性能指标： Performance
• 内存指标: Memory
• 基本活动指标：Basic activity
• 持久性指标: Persistence
• 错误指标： Error

性能指标：Performance

内存指标: Memory

基本活动指标：Basic activity

持久性指标: Persistence

错误指标： Error

监控方式

redis-benchmark
redis-stat
redis-faina
redislive
redis-cli

• monitor
• showlog
  1）get：获取慢查询日志
  2）len：获取慢查询日志条目数
  3）reset：重置慢查询日志
  相关配置：
  slowlog-log-slower-than 1000 # 设置慢查询的时间下线，单位：微秒
  slowlog-max-len 100 # 设置慢查询命令对应的日志显示长度，单位：命令数
• info（可以一次性获取所有的信息，也可以按块获取信息）
  1）server:服务器运行的环境参数
  2）clients:客户端相关信息
  3）memory：服务器运行内存统计数据
  4）persistence：持久化信息
  5）stats：通用统计数据
  6）Replication：主从复制相关信息
  7）CPU：CPU使用情况
  8）cluster：集群信息
  9）Keypass：键值对统计数量信息

终端info命令使用

./redis-cli info 按块获取信息 | grep 需要过滤的参数
./redis-cli info stats | grep ops

交互式info命令使用

 #./redis-cli 
> info server

性能监控

redis-cli info | grep ops # 每秒操作数

[root@c71 ~]# redis-cli info | grep ops
instantaneous_ops_per_sec:0

内存监控

Redis的内存占用主要包括自身内存 + 对象内存 + 缓冲内存 + 内存碎片

• 自身内存占用包括Redis进程初始化时创建的一些共享对象, 以及为事件驱动创建的aeEventLoop, 还有为保证服务正常运行所创建的一些数据结构.
• 对象内存理论上应该是占Redis总内存的最大一块, 里面存储着用户的所有数据, 而用户数据的表现形式是RedisObject, 这个在之前的博客Redis中的对象中有介绍过.
• 缓冲内存包括了客户端连接的缓冲区, 复制积压缓冲区, 还有AOF缓冲区等等
• 内存碎片实际上就是在分配内存时需要考虑边界对齐所额外分配的内存, 以及由于释放了某些内存块但是又不能被分配器重新使用而造成的消耗
  造成堆利用率很低的主要原因是一种称为碎片(fragmentation)的现象, 当虽然有未使用的存储器但不能用来满足分配请求时, 就会发生这种现象, 有两种形式的碎片: 内部碎片(internal fragmentation)和外部碎片(external fragmentation).
• 内部碎片是在一个已分配块比有效荷载大时发生的. 很多原因都可能造成这个问题. 例如, 一个分配器的实现可能对已分配块强加一个最小的最大值, 而这个大小要比某个请求的有效载荷大.
• 外部碎片是当空闲存储器合计起来足够满足一个分配请求, 但是没有一个单独的空闲块足够大可以来处理这个请求时发生的, 例如现在有四个分散的, 大小都为2 Bytes的空闲块, 而现在有一个请求要求8 Bytes, 空闲块的总体积确实是8 Bytes, 但是由于它们并不连续, 所以不能满足请求.
  外部碎片比内部碎片的量化要困难得多, 因为它不仅仅取决于以前请求的模式和分配器的实现方式, 还取决于将来请求的模式. 例如, 假设在k个请求之后, 所有空闲块的大小都恰好是4个字, 这个堆会有外部碎片吗? 答案取决于将来的请求模式. 如果将来所有的分配请求都要求小于或者等于4个字的块, 那么就不会有外部碎片. 另一方面, 如果有一个或者多个请求要求比4个字大的块, 那么这个堆就会有外部碎片.

[root@c71 ~]# redis-cli info memory
介绍部分
used_memory_human:846.20K  # 内存分配器从操作系统分配的内存总量，是Redis层面调用zmalloc等函数所分配的内存总量, 也就是 zmalloc_used_memory()
used_memory_rss_human:7.62M  # 操作系统看到的内存占用，top命令看到的内存
used_memory_peak_human:846.20K  # redis内存消耗的峰值
used_memory_lua_human:37.00K  # lua脚本引擎占用的内存大小，是在Redis的Lua三方库中分配的内存, 其内部走的是malloc()/free()的形式控制内存
used_memory_scripts_human:0B  # 实际上就是Redis缓存Lua脚本所占用的内存, 需要注意的是, 由于缓存Lua脚本创建对象都是调用的Redis层面的ZMalloc等函数, 所以这部分的内存消耗实际上是包含在 used_memory 内部的.
number_of_cached_scripts:0  # 就很好理解了, 就是Redis中缓存Lua脚本的个数, 实际上就是 server.lua_scripts 的大小.
mem_fragmentation_ratio:9.95  # 是将(Redis进程常驻内存/Redis通过Zmalloc等函数分配内存)得到的一个比值( process_rss/zmalloc_used ), 作者应该是想通过它表示用户实际数据占用内存相对于进程常驻内存的一个占比, 但是自己觉得不是特别准确.

由于BLPOP,BRPOP,or BRPOPLPUSH而备阻塞的客户端

[root@c71 ~]# redis-cli info | grep blocked_clients
blocked_clients:0

由于最大内存限制被移除的key的数量

[root@c71 ~]# redis-cli info | grep evicted_keys
evicted_keys:0

内存碎片率

[root@c71 ~]# redis-cli info | grep mem_fragmentation_ratio
mem_fragmentation_ratio:9.94

已使用内存

[root@c71 ~]# redis-cli info | grep used_memory:
used_memory:866504

基本活动指标

redis连接了多少客户端
通过观察其数量可以确认是否存在意料之外的连接。如果发现数量不对劲，就可以使用lcient list指令列出所有的客户端链接地址来确定源头。

[root@c71 ~]# redis-cli info | grep connected_clients
connected_clients:2
[root@c71 ~]# redis-cli info | grep connected
connected_clients:2  # 客户端连接数量
connected_slaves:0  # slave连接数量

持久性指标

[root@c71 ~]# redis-cli info | grep rdb_last_save_time
rdb_last_save_time:1656147048  # 最后一次持久化保存磁盘的时间戳
[root@c71 ~]# redis-cli info | grep rdb_changes_since_last_save
rdb_changes_since_last_save:0  # 自最后一次持久化以来数据库的更改数

错误指标

由于超出最大连接数限制而被拒绝的客户端连接次数，如果这个数字很大，则意味着服务器的最大连接数设置得过低，需要调整maxclients\

[root@c71 ~]# redis-cli info | grep connected_clients
connected_clients:2

key值查找失败(没有命中)次数，出现多次可能是被 攻击 了

[root@c71 ~]# redis-cli info | grep keyspace
keyspace_hits:0
keyspace_misses:0

主从断开的持续时间（以秒为单位)

[root@c71 ~]# redis-cli info | grep rdb_changes_since_last_save
rdb_changes_since_last_save:0

复制积压缓冲区如果设置得太小，会导致里面的指令被覆盖掉找不到偏移量，从而触发全量同步

[root@c71 ~]# redis-cli info | grep backlog_size
repl_backlog_size:1048576

通过查看sync_partial_err变量的次数来决定是否需要扩大积压缓冲区，它表示主从半同步复制失败的次数

[root@c71 ~]# redis-cli info | grep sync_partial_err
sync_partial_err:0

redis性能测试命令

redis-benchmark -c 100 -n 5000
说明：100个连接，5000次请求对应的性能