网站title怎么修改,如何开通网站,邢台市的做网站制作公司,郑州网站设计制作价格如果观察到#xff0c;这个实例的运行延迟是正常 Redis 基准性能的 2 倍以上#xff0c;即可认为这个 Redis 实例确实变慢了。
1.如何查看实例的运行延迟 #xff08;1#xff09;redis-cli -h 127.0.0.1 -p 6379 --intrinsic-latency 60 执行该命令#xff0c;就可以测… 如果观察到这个实例的运行延迟是正常 Redis 基准性能的 2 倍以上即可认为这个 Redis 实例确实变慢了。
1.如何查看实例的运行延迟 1redis-cli -h 127.0.0.1 -p 6379 --intrinsic-latency 60 执行该命令就可以测试出这个实例 60 秒内的最大响应延迟如下图 从输出结果可以看到这 60 秒内的最大响应延迟为 72 微秒0.072毫秒
2redis-cli -h 127.0.0.1 -p 6379 --latency-history -i 1 通过该命令查看一段时间内 Redis 的最小、最大、平均访问延迟如下图 以上输出结果是每间隔 1 秒采样 Redis 的平均操作耗时其结果分布在 0.08 ~ 0.13 毫秒之间。
3执行redis-benchmark -h 127.0.0.1 -p 6379 -t set,lpush -n 100000 -c 50这个命令会模拟50个并发客户端每个客户端发送10万个请求请求命令为set,lpush如果省略每种命令都会执行一遍对指定的Redis服务器进行性能测试。
2.使用复杂度过高的命令 通过SLOWLOG get 5命令查看 Redis 的慢日志slowlog找出执行慢的命令操作。 如果应用程序执行的Redis命令有以下特点那么有可能会导致操作延迟变大 经常使用 O(N) 以上复杂度的命令例如 SORT、SUNION、ZUNIONSTORE 聚合类命令 导致变慢的原因在于Redis 在操作内存数据时时间复杂度过高要花费更多的 CPU 资源 优化建议对于数据的聚合操作放在客户端做 使用 O(N) 复杂度的命令但 N 的值非常大 导致变慢的原因在于Redis 一次需要返回给客户端的数据过多更多时间花费在数据协议的组装和网络传输过程中 优化建议 执行 O(N) 命令保证 N 尽量的小推荐 N 300每次获取尽量少的数据让 Redis 可以及时处理返回 N表示命令的个数
3.操作bigkey 如果查询慢日志发现并不是复杂度过高的命令导致的而都是 SET / DEL 这种简单命令出现在慢日志中那么就要怀疑实例否写入了 bigkey。 如果一个key写入的value非常大那么Redis在分配内存时就会比较耗时。同样的当删除这个key时释放内存也会比较耗时。 通过使用bigkey的命令扫描大值key 其实使用这个命令的原理就是 Redis 在内部执行了 SCAN 命令遍历整个实例中所有的 key然后针对 key 的类型分别执行 STRLEN、LLEN、HLEN、SCARD、ZCARD 命令来获取 String 类型的长度、容器类型List、Hash、Set、ZSet的元素个数。 优化建议 业务应用尽量避免写入 bigkey 如果你使用的 Redis 是 4.0 以上版本用 UNLINK 命令替代 DEL此命令可以把释放 key 内存的操作放到后台线程中去执行从而降低对 Redis 的影响 如果你使用的 Redis 是 6.0 以上版本可以开启 lazy-free 机制lazyfree-lazy-user-del yes在执行 DEL 命令时释放内存也会放到后台线程中执行
4.集中过期 如果发现平时在操作 Redis 时并没有延迟很大的情况发生但在某个时间点突然出现一波延时其现象表现为变慢的时间点很有规律例如某个整点或者每间隔多久就会发生一波延迟。如果是出现这种情况那么需要排查一下业务代码中是否存在设置大量 key 集中过期的情况。
1为什么集中过期会导致 Redis 延迟变大 答Redis 的过期数据采用被动过期 主动过期两种策略 被动过期只有当访问某个 key 时才判断这个 key 是否已过期如果已过期则从实例中删除 主动过期Redis 内部维护了一个定时任务默认每隔 100 毫秒1秒10次就会从全局的过期哈希表中随机取出 20 个 key然后删除其中过期的 key如果过期 key 的比例超过了 25%则继续重复此过程直到过期 key 的比例下降到 25% 以下或者这次任务的执行耗时超过了 25 毫秒才会退出循环 注意这个主动过期 key 的定时任务是在 Redis 主线程中执行的。也就是说如果在执行主动过期的过程中出现了需要大量删除过期 key 的情况那么此时应用程序在访问 Redis 时必须要等待这个过期任务执行结束Redis 才可以服务这个客户端请求。此时就会出现应用访问 Redis 延时变大。如果此时需要过期删除的是一个 bigkey那么这个耗时会更久。而且这个操作延迟的命令并不会记录在慢日志中。因为慢日志中只记录一个命令真正操作内存数据的耗时而 Redis 主动删除过期 key 的逻辑是在命令真正执行之前执行的。 优化建议 集中过期 key 增加一个随机过期时间把集中过期的时间打散降低 Redis 清理过期 key 的压力 如果你使用的 Redis 是 4.0 以上版本可以开启 lazy-free 机制当删除过期 key 时把释放内存的操作放到后台线程中执行避免阻塞主线程。 lazyfree-lazy-expire yes
5.实例内存达到上限 如果你的Redis实例设置了内存上限maxmemory那么也有可能导致Redis变慢当Redis内存达到maxmemory后每次写入新的数据之前Redis必须先从实例中踢出一部分数据让整个实例的内存维持在maxmemory之下然后才能把新数据写进来。这个踢出旧数据的逻辑也是需要消耗时间的而具体耗时的长短要取决于你配置的淘汰策略。 需要注意的是Redis 的淘汰数据的逻辑与删除过期 key 的一样也是在命令真正执行之前执行的也就是说它也会增加我们操作 Redis 的延迟而且写 OPS 越高延迟也会越明显。 优化建议 避免存储 bigkey降低释放内存的耗时 淘汰策略改为随机淘汰随机淘汰比 LRU 要快很多视业务情况调整 拆分实例把淘汰 key 的压力分摊到多个实例上 如果使用的是 Redis 4.0 以上版本开启 layz-free 机制把淘汰 key 释放内存的操作放到后台线程中执行配置 lazyfree-lazy-eviction yes
6.fork耗时严重 主进程创建子进程 RDB 和 AOF 会调用操作系统提供的fork函数。而fork在执行过程中主进程需要拷贝自己的内存页表给子进程如果这个实例很大那么这个拷贝的过程也会比较耗时。而且这个fork过程会消耗大量的CPU资源在完成fork之前整个Redis实例会被阻塞住无法处理任何客户端请求。 1那如何确认确实是因为 fork 耗时导致的 Redis 延迟变大呢 答在Redis上执行INFO命令查看latest_fork_usec项单位微秒。latest_fork_usec:59477 这个时间就是主进程在fork子进程期间整个实例阻塞无法处理客户端请求的时间 如果发现这个耗时很久就要警惕起来了这意味在这期间整个 Redis 实例都处于不可用的状态。 优化建议 控制 Redis 实例的内存尽量在 10G 以下执行 fork 的耗时与实例大小有关实例越大耗时越久 合理配置数据持久化策略在 slave 节点执行 RDB 备份推荐在低峰期执行而对于丢失数据不敏感的业务例如把 Redis 当做纯缓存使用可以关闭 AOF 和 AOF rewrite Redis 实例不要部署在虚拟机上fork 的耗时也与系统也有关虚拟机比物理机耗时更久 降低主从库全量同步的概率适当调大 repl-backlog-size 参数环形内存的大小避免主从全量同步
7.开启内存大页 我们都知道应用程序向操作系统申请内存时是按内存页进行申请的而常规的内存页大小是 4KB。Linux 内核从 2.6.38 开始支持了内存大页机制该机制允许应用程序以 2MB 大小为单位向操作系统申请内存。应用程序每次向操作系统申请的内存单位变大了但这也意味着申请内存的耗时变长。
1这对 Redis 会有什么影响呢 答主要跟redis的 Copy On Write机制有关。 主进程在拷贝内存数据时这个阶段就涉及到新内存的申请如果此时操作系统开启了内存大页那么在此期间客户端即便只修改 10B 的数据Redis 在申请内存时也会以 2MB 为单位向操作系统申请申请内存的耗时变长进而导致每个写请求的延迟增加影响到 Redis 性能。 同样地如果这个写请求操作的是一个 bigkey那主进程在拷贝这个 bigkey 内存块时一次申请的内存会更大时间也会更久。 优化建议 对于 Redis 这种对性能和延迟极其敏感的数据库来说我们希望Redis在每次申请内存时耗时尽量短所以不建议你在Redis机器上开启这个机制。 查看 Redis 机器是否开启了内存大页 cat /sys/kernel/mm/transparent_hugepage/enabled 关闭redis内存大页机制 :echo never /sys/kernel/mm/transparent_hugepage/enabled
8.AOF刷盘机制 根据业务需求选择AOF三种不同的刷盘时机不同的处理策略会提升redis的性能。 在 Redis.conf 配置文件中的 appendfsync 配置项可以有以下 3 种参数可填 Always这个单词的意思是「总是」所以它的意思是每次写操作命令执行完后同步将 AOF 日志数据写回硬盘主线程 Everysec这个单词的意思是「每秒」所以它的意思是每次写操作命令执行完后先将命令写入到 AOF 文件的内核缓冲区然后每隔一秒将缓冲区里的内容写回到硬盘 AOF 刷盘线程异步 No意味着不由 Redis 控制写回硬盘的时机转交给操作系统控制写回的时机也就是每次写操作命令执行完后先将命令写入到 AOF 文件的内核缓冲区再由操作系统决定何时将缓冲区内容写回硬盘。
9.使用Swap 如果发现 Redis 突然变得非常慢每次的操作耗时都达到了几百毫秒甚至秒级那此时就需要检查Redis是否使用到了 Swap在这种情况下Redis基本上已经无法提供高性能的服务了。 1什么是swap? 答如果对操作系统有些了解就会知道操作系统为了缓解内存不足对应用程序的影响允许把一部分内存中的数据换到磁上以达到应用程序对内存使用的缓冲这些内存数据被换到磁盘上的区域就是 Swap。问题就在于当内存中的数据被换到磁盘上后Redis 再访问这些数据时就需要从磁盘上读取访问磁盘的速度要比访问内存慢几百倍
2 查看Redis 进程是否使用到了 Swap 答# 先找到 Redis 的进程 ID $ ps -aux | grep redis-server # 查看 Redis Swap 使用情况 $ cat /proc/$pid/smaps | egrep ^(Swap|Size) 输出结果如下 每一行Size表示Redis所用的一块内存大小Size下面的Swap就表示这块Size大小的内存有多少数据已经被换到磁盘上了如果这两个值相等说明这块内存的数据都已经完全被换到磁盘上了。如果只是少量数据被换到磁盘上例如每一块Swap占对应Size的比例很小那影响并不是很大。如果是几百兆甚至上GB的内存被换到了磁盘上那么你就需要警惕了这种情况Redis的性能肯定会急剧下降。 优化建议 增加机器的内存让 Redis 有足够的内存可以使用 整理内存空间释放出足够的内存供 Redis 使用然后释放 Redis 的 Swap让 Redis 重新使用内存
10.碎片整理 Redis 的数据都存储在内存中当我们的应用程序频繁修改 Redis 中的数据时就有可能会导致 Redis 产生内存碎片内存碎片会降低 Redis 的内存使用率
1如何计算碎片率 答可以通过执行 INFO 命令得到这个实例的内存碎片率 mem_fragmentation_ratio used_memory_rss / used_memory。其中 used_memory 表示 Redis 存储数据的内存大小而 used_memory_rss 表示操作系统实际分配给 Redis 进程的大小。如果 mem_fragmentation_ratio 1.5说明内存碎片率已经超过了 50%这时我们就需要采取一些措施来降低内存碎片了。 优化建议 如果你使用的是 Redis 4.0 以下版本只能通过重启实例来解决 如果你使用的是 Redis 4.0 版本它正好提供了自动碎片整理的功能可以通过配置开启碎片自动整理开启自动内存碎片整理(总开关):activedefrag yes;当碎片达到 100mb 时开启内存碎片整理:active-defrag-ignore-bytes 100mb; 当碎片超过 10% 时开启内存碎片整理:active-defrag-threshold-lower 10;内存碎片超过 100%则尽最大努力整理:active-defrag-threshold-upper 100;内存自动整理占用资源最小百分比:active-defrag-cycle-min 25; 内存自动整理占用资源最大百分比:active-defrag-cycle-max 75。 但是开启内存碎片整理它也有可能会导致 Redis 性能下降原因在于Redis 的碎片整理工作是也在主线程中执行的当其进行碎片整理时必然会消耗 CPU 资源产生更多的耗时从而影响到客户端的请求。所以当你需要开启这个功能时最好提前测试评估它对 Redis 的影响。
