关于宠物的网站模板,应用市场,做企业网站的广告词,从事网络销售都有哪些平台呢在实际应用中#xff0c;你是否遇到过这样的情况#xff0c;本来Redis运行的好好的#xff0c;响应也挺正常#xff0c;但突然就变慢了#xff0c;响应时间增加了#xff0c;这不仅会影响用户体验#xff0c;还会牵连其他系统。 那如何排查Redis变慢的情况呢#xff1f… 在实际应用中你是否遇到过这样的情况本来Redis运行的好好的响应也挺正常但突然就变慢了响应时间增加了这不仅会影响用户体验还会牵连其他系统。 那如何排查Redis变慢的情况呢首先有个问题需要确定就是确定Redis是否真的变慢了。
Redis基线性能 要判断Redis是否变慢了一个最直接的方法就是查看Redis的响应时间。 大部分情况下Redis的延迟很低但是在某些情况下Redis会出现很高的延迟可能会达到几秒甚至更长不过持续的时间又不长这到底是怎么情况呢如果出现了响应延迟到秒级别就可以确定Redis变慢了。 首先需要先确定Redis的延迟绝对值但是在不同运行环境下Redis的绝对性能是不同的。所以就需要当前环境的基线性能所谓基线性能就是一个系统在低压力、无干扰下的基本性能这个性能只由当前软硬件环境配置决定。 基线性能可以通过Redis提供的命令来确定具体为在redis-cli中添加--intrinsic-latency选项可以用来检测和统计Redis在运行期间内的最大延迟这就可以作为基线性能。
redis-cli -h localhost --intrinsic-latency 120
Max latency so far: 1 microseconds.
Max latency so far: 29 microseconds.
Max latency so far: 31 microseconds.
Max latency so far: 34 microseconds.
Max latency so far: 53 microseconds.
Max latency so far: 68 microseconds.
Max latency so far: 103 microseconds.
Max latency so far: 106 microseconds.
Max latency so far: 142 microseconds.
Max latency so far: 158 microseconds.
Max latency so far: 164 microseconds.
Max latency so far: 273 microseconds.
Max latency so far: 296 microseconds.
Max latency so far: 673 microseconds.
Max latency so far: 946 microseconds.
Max latency so far: 2138 microseconds.
Max latency so far: 2234 microseconds.
Max latency so far: 16164 microseconds.2383205581 total runs (avg latency: 0.0504 microseconds / 50.35 nanoseconds per run).
Worst run took 321018x longer than the average latency. 在自己的电脑上运行命令后会打印120秒内检测到的最大延迟可以看到这里的最大延迟为16164微妙16ms左右。一般情况下检测120s的时长已经够了。 一般来说运行时响应时间和基线性能做对比如果响应时间达到了基线性能的2倍以上就可以认定Redis变慢了。
Redis变慢的原因 一旦发现变慢了接下来就要查找原因解决这个问题了。这个过程要基于Redis本身的工作原理并结合和它交互的操作系统、存储以及网络等外部系统的关键机制在借助一些辅助工具来定位问题并指定行之有效的解决方案。 Redis变慢的原因有几下几点如图所示 慢查询指令 慢查询命令指在Redis中执行速度慢的命令这会导致Redis延迟增加。Redis提供的命令操作很多并不是所有命令都慢这和命令操作的复杂度有关所以我们必须知道不同命令的复杂度。 比如操作的value为String类型时由于操作的事hash表这个操作的复杂度是固定的都是O(1)除非出现了hash碰撞严重。但操作的数据类型为集合时如果集合中包含大量的元素那这个操作复杂度是比较高的会比较耗时。 Redis官网提供了各个命令的复杂度Commands | Redishttps://redis.io/commands/ 如果有复杂的操作就要考虑是否需要用简单的命令来替换。如果使用keys命令查询大量的key也会导致慢查询因为需要扫描所有的键值对所以生产环境要禁用这样的命令。 删除key操作 如果Redis中key过期了是会被自动删除的这也是Redis的回收机制Redis 的 key可以设置过期时间默认情况下每100ms就会扫描一次删除过期的key具体如下
采样ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP个数的key并将其中过期的key全部删除如果超过25%的key过期了则重复删除过程直到过期key的比例降至25%以下。 如果触发了第二条规则Redis就会一直删除以释放内存空间。注意删除操作是阻塞的(Redis 4.0提供了异步机制减少阻塞)。所以一旦触发了就会一直删除key这样一来就没办法给客户端提供服务了。 磁盘I/OAOF 为了保证数据的可靠性Redis提供了AOF和RDB两种机制(想具体了解请查看Redis持久化(AOF、RDB)用到的写时复制到底是什么-CSDN博客)。其中AOF提供了三种写回策略always、everysec、no这三种写回策略依赖文件系统来完成也就是write和fsync。 write把日志写到内核的缓冲区就可以返回了并不需要等待日志实际写回磁盘而fsync需要把日志记录写回到磁盘才能返回时间较长。 当写回策略配置为everysec和always时Redis需要调用fsync把日志写回磁盘。但是这两种写回策略的具体情况不一样。但不管怎么说都会涉及到写回磁盘而且fsync通常比较耗时如果Redis主线程执行写回就会造成阻塞。 另外AOF日志重写时也容易阻塞主线程所以Redis使用了子线程来完成该操作。但是AOF重写会对磁盘又大量的IO操作同时fsync又需要等到数据写到磁盘才能返回所以当AOF重写的压力比较大时就会导致fsync阻塞虽然fsync由后台子线程完成但是主线程会监测fsync的执行进度。 当主线程使用子线程执行了一次fsync需要再次把接收的数据写回磁盘如果主线程发现上一次的fsync还没有执行完那么它就会阻塞。所以如果后台线程执行fsync频繁阻塞的话主线程也会阻塞导致Redis性能变慢。 内存大页 内存大页机制也会影响Redis性能。Linux内核从2.6.38开始支持内存大页支持2MB大小的内存页分配而常规的也大小是4KB。你可能会说Redis是内存数据库内存大页对Redis不是有好处的吗减少了内存的分配但是任何事都有两面性这时一个权衡的过程。 Redis为了提高可靠性提供了持久化的机制。这个过程需要额外的线程来执行所以不会阻塞主线程为客户端提供服务。如果在持久化的过程中客户端修改了数据Redis会才用写时复制(Copy On Write)机制数据一旦修改了不会直接修改内存中的数据而是复制一份然后再进行修改。 如果采用了内存大页那Redis就需要拷贝该大页。如果关闭了内存大页那需要拷贝的页数据只有4kb可见内存大页会复制大量数据。 所以正常情况下关闭内存大页就可以了。 swap操作 操作系统swap是将内存数据在内存和磁盘来回换入核换出的机制涉及到磁盘的读写。所以一旦涉及到了swap其性能都会收到磁盘性能的影响。 Redis是内存数据库内存使用量大如果用Redis保存海量数据而且没有控制好内存使用量就可能会触发swap机制从而影响性能。一旦触发swap机制Redis需要操作磁盘才能完成这回极大的降低Redis的性能。 关于海量数据的处理请参考面对海量数据Redis如何应对-CSDN博客 Redis对于swap的排查有现成的命令具体这里不做详细介绍了。 内存碎片 内存碎片很好理解明明有内存空间但是申请时就是无法分配需要的内存空间这对于使用内存的Redis来说无疑影响巨大。 内存碎片的原因
内存不是按需分配的操作系统为了减少内存的分配次数每次都是按照固定大小进行内存分配的例如8字节、16字节、32字节等比如申请了20字节的内存但是实际上会分配32字节此时如果在写入5字节数据就不用再申请内存了减少了内存申请的次数。Redis键值对大小不一和删除操作的影响内存分配器只能按照固定大小分配内存。所以分配的内存空间一般都会比申请的空间大一些不会完全一直这本身就会造成一定碎片降低内存空存储效率。键值对会被修改或删除这会导致空间的扩容和释放。一方面如果修改后的键值对变大或变小了就需要占用额外的空间或释放不用的空间。另一方面删除的键值对就不在需要内存空间了此时会把空间释放出来变成空闲空间。 如何判断内存碎片 Redis是内存数据库内存利用率的高低直接关系到Redis运行效率的高低。为了让用户能监控到实时的内存使用情况Redis自身提供了info命令可以用来查询内存使用的详细信息
info memory
# Memory
used_memory:1143520
used_memory_human:1.09M
used_memory_rss:1114112
used_memory_rss_human:1.06M
used_memory_peak:1144672
used_memory_peak_human:1.09M
used_memory_peak_perc:99.90%
used_memory_overhead:1096754
used_memory_startup:1079248
used_memory_dataset:46766
used_memory_dataset_perc:72.76%
allocator_allocated:1098416
allocator_active:1076224
allocator_resident:1076224
total_system_memory:8589934592
total_system_memory_human:8.00G
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.1
allocator_frag_bytes:18446744073709529424
allocator_rss_ratio:1.00
allocator_rss_bytes:0
rss_overhead_ratio:1.04
rss_overhead_bytes:37888
mem_fragmentation_ratio:1.01
mem_fragmentation_bytes:15696
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:16986
mem_aof_buffer:0
mem_allocator:libc
active_defrag_running:0
lazyfree_pending_objects:0 mem_fragmentation_ratio指标表示内存碎片化率该值大于1但小于1.5时这种情况是正常的因为内存碎片是无法避免的。如果该值大于1.5就表名内存碎片化率比较严重了超过了50%这时需要采取措施来处理内存碎片化。 Redis从4.0版本后提供了专门清理内存碎片化的参数通过该参数来设置内存碎片化的清理的开始和结束时机以及占用CPU比例从而减少碎片清理对Redis本身请求处理的性能影响。
config set activedefrag yes 这个命令只是启动了自动清理功能但具体什么时候清理会受下面两个参数的控制。这两个参数分别设置了触发内存清理的一个条件如果同时满足这两个条件就开始清理清理过程中只要有一个条件不满足就停止清理。
active-defrag-ignore-bytes 100mb表示内存碎片的字节数达到100MB时就开始清理。active-defrag-threshold-lower 10:表示内存碎片空间占操作系统分配给Redis的总空间比例达到10%时开始清理。
总结 关于Redis变慢的问题排查就介绍到这里不知道你有没有清晰的思路欢迎关注并留言讨论。
