成都网站制作价格seo中文含义

对运行状态的Redis实例进行监控是运维管理中非常重要的内容，包括：监控Redis的内存、监控Redis的吞吐量、监控Redis的运行时信息和监控Redis的延时。通过Redis提供的监控命令便能非常方便地实现对各项指标的监控。

一、监控Redis的内存

视频讲解如下
【赵渝强老师】监控Redis的内存

Redis监控内存最直接的方法当然就是使用系统提供的info命令来做了。只需要执行下面一条命令，就能获得Redis关于内存的状态报告。

bin/redis-cli info |grep mem输出的信息如下：
used_memory:873720 					Redis分配的总内存量。
used_memory_human:853.24K 			以可读方式展示Redis分配的总内存量。
used_memory_rss:9809920 			Redis总占用内存量。
used_memory_rss_human:9.36M 		可读方式展示Redis总占用内存量。
used_memory_peak:931792 			内存使用量的峰值。
used_memory_peak_human:909.95K 		可读方式展示内存使用量的峰值。
used_memory_peak_perc:93.77% 		内存使用量峰值的百分比。
used_memory_overhead:810000 		缓冲区等占用的内存。
used_memory_startup:809992 			启动Redis实例时消耗的内存。
used_memory_dataset:63720 			Redis数据所占用的内存。
used_memory_dataset_perc:99.99%		Redis数据所占用内存的百分比。
total_system_memory:4126871552 		操作系统总内存。
total_system_memory_human:3.84G 	可读方式展示操作系统总内存。
used_memory_lua:37888 				LUA脚本消耗的内存。
used_memory_lua_human:37.00K 		可读方式展示LUA脚本消耗的内存。
used_memory_scripts:0
used_memory_scripts_human:0B
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:12.11 		内存的碎片率。
mem_fragmentation_bytes:8999912 	内存碎片的大小。
mem_not_counted_for_evict:4
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:0
mem_aof_buffer:8
mem_allocator:jemalloc-5.1.0 		Redis内存分配器版本。

二、监控Redis的吞吐量

视频讲解如下
【赵渝强老师】监控Redis的吞吐量

通过执行下面命令可以监控Redis的吞吐量。

127.0.0.1:6379 > info stats
输出的信息如下：
# Stats
total_connections_received:1 	总的连接数请求。
total_commands_processed:1 		从Redis启动以来总计处理的命令数。
instantaneous_ops_per_sec:0 	当前Redis实例的OPS。
total_net_input_bytes:42 		网络总入量。
total_net_output_bytes:20324 	网络总出量。
instantaneous_input_kbps:0.00 	每秒输入量，单位是kb/s。
instantaneous_output_kbps:0.00 	每秒输出量，单位是kb/s。
rejected_connections:0 			被拒绝的连接数。
......

三、监控Redis的运行时信息

视频讲解如下
【赵渝强老师】监控Redis的运行时信息

Redis提供的info命令不仅能够查看实时的吞吐量(ops/sec)，还能看到一些有用的运行时信息。下面用grep过滤出一些比较重要的实时信息，比如已连接的和在阻塞的客户端、已用内存、拒绝连接、实时的tps和数据流量等。执行下面的命令：

bin/redis-cli info | \
grep -e "connected_clients" \
-e "blocked_clients" \
-e "used_memory_human" \
-e "used_memory_peak_human" \
-e "rejected_connections" \
-e "evicted_keys" \
-e "instantaneous"输出的信息如下：
connected_clients:2 			已连接的客户端数。
blocked_clients:0 				已阻塞的客户端数
used_memory_human:2.41G 		已使用的内存大小。
used_memory_peak_human:2.41G 	已使用内存大小的峰值。
instantaneous_ops_per_sec:0 	每秒处理的指令数。
instantaneous_input_kbps:0.00 	每秒读取的字节数。
instantaneous_output_kbps:0.00 	每秒写入的字节数
rejected_connections:0 			被拒绝的连接数。
evicted_keys:0 					Redis实例启动以来被删除的键的数量。

四、监控Redis的延时

视频讲解如下
【赵渝强老师】监控Redis的延时

Redis中的延时可以通过客户端进行手动的监控，也可以由服务器内部进行自动的延迟监控。从客户端可以监控Redis的延迟，利用Redis提供的PING命令，不断PING服务端，记录服务端响应PONG的时间。下面开两个终端，一个监控延迟，一个监视服务端收到的命令。如果我们故意用DEBUG命令制造延迟，就能看到一些输出上的变化。

服务端内部的延迟监控稍微麻烦一些，因为延迟记录的默认阈值是0。尽管空间和时间耗费很小，Redis为了高性能还是默认关闭了它。所以首先我们要开启它，设置一个合理的阈值。

下面通过具体的示例来进行演示。

（1）执行下面的命令使用Redis客户端进行手动监控。

bin/redis-cli --latency输出的信息如下：
min: 0, max: 1, avg: 0.22 (211 samples)提示：此时会发现Redis一直在执行延时监控，并将结果输出到屏幕上。

（2）新开启一个Redis客户端，通过debug命令手动触发一个延时。

127.0.0.1:6379 > debug sleep 2

（3）观察第（1）步中输出的信息。

min: 0, max: 1991, avg: 0.40 (7557 samples)提示：这时候可以看出Redis监控到目前产生的最大演示是1991毫秒，即2秒左右。

（4）查看服务器内部监控的阈值设定。

127.0.0.1:6379> config get latency-monitor-threshold输出的信息如下：
1) "latency-monitor-threshold"
2) "0"提示：在默认情况下，Redis关闭了延迟的服务器内部监控机制。

（5）设置服务器内部监控阈值是100毫秒。

127.0.0.1:6379> config set latency-monitor-threshold 100

（6）手动触发一些延迟。

127.0.0.1:6379 > debug sleep 2
127.0.0.1:6379 > debug sleep .15
127.0.0.1:6379 > debug sleep .5

（7）使用latency命令查看产生的延迟信息。

# 查看最近一次产生的延迟。
127.0.0.1:6379> latency latest
1) 1) "command"
2) (integer) 1650195297
3) (integer) 501
4) (integer) 2000# 查看延迟的时间序列。
127.0.0.1:6379 > latency history command
1) 1) (integer) 1650195290
2) (integer) 2000
2) 1) (integer) 1650195292
2) (integer) 152
3) 1) (integer) 1650195297
2) (integer) 501# 以图形化的方式显示延迟。
127.0.0.1:6379 > latency graph command
command - high 2000 ms, low 152 ms (all time high 2000 ms)
----------------------------------------------------------
#
|
|
|_#
115
mm5
s

（8）使用Redis提供的优化延迟指导。

127.0.0.1:6379 > latency doctor输出的信息如下：
Dave, I have observed latency spikes in this Redis instance. You don't mind talking about it, do you Dave?
1. command: 3 latency spikes (average 884ms, mean deviation 743ms, period 92.67 sec). Worst all time event 2000ms.
I have a few advices for you:
- Check your Slow Log to understand what are the commands you are running which are too slow to execute. Please check https://redis.io/commands/slowlog for more information.- Deleting, expiring or evicting (because of maxmemory policy) large objects is a blocking operation. If you have very large objects that are often deleted, expired, or evicted, try to fragment those objects into multiple smaller objects.- I detected a non zero amount of anonymous huge pages used by your process. This creates very serious latency events in different conditions, especially when Redis is persisting on disk. To disable THP support use the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled', make sure to also add it into /etc/rc.local so that the command will be executed again after a reboot. Note that even if you have already disabled THP, you still need to restart the Redis process to get rid of the huge pages already created.提示：Redis提供的延迟指导可以帮助定位延迟产生的原因，并提供了一些解决的方案。从上面的输出中可以看出，doctor命令给出了三点优化的建议。

（9）使用Redis延迟度量的基线。

bin/redis-cli --intrinsic-latency 100提示：度量是指一段时间内，某一性能指标的累计值。延迟中的一部分是来自环境的，比如操作系统内核、虚拟化环境等等。Redis提供了度量这一部分延迟基线的方法。输出的信息如下：
Max latency so far: 1 microseconds.
Max latency so far: 16 microseconds.
Max latency so far: 17 microseconds.
Max latency so far: 82 microseconds.
Max latency so far: 116 microseconds.
Max latency so far: 169 microseconds.
Max latency so far: 388 microseconds.
Max latency so far: 1488 microseconds.
Max latency so far: 6807 microseconds.
Max latency so far: 10914 microseconds.
Max latency so far: 13091 microseconds.
Max latency so far: 14162 microseconds.
1594254423 total runs (avg latency: 0.0627 microseconds / 62.73 nanoseconds per run).Worst run took 225778x longer than the average latency.