做网站收获了什么,wordpress 免费弹窗插件,浅谈博物馆网站建设的意义,做网站 如何注册公司文章目录 一、定义二、慢查询参数配置三、慢查询日志四、排查步骤五、Redis变慢原因 一、定义 在Redis执行时耗时超过某个阈值的命令#xff0c;称为慢查询。 慢查询日志帮助开发和运维人员定位系统存在的慢操作。慢查询日志就是系统在命令执行前后计算每条命令的执行时间称为慢查询。 慢查询日志帮助开发和运维人员定位系统存在的慢操作。慢查询日志就是系统在命令执行前后计算每条命令的执行时间当超过预设阀值就将这条命令的相关信息慢查询ID发生时间戳耗时命令的详细信息记录下来。 二、慢查询参数配置 1、通过配置指定慢查询的阈值 slowlog-log-slower-than慢查询阈值单位是微秒。默认是10000建议1000 2、慢查询会被放入慢查询日志中日志的长度有上限可以通过配置指定 slowlog-max-len慢查询日志本质是一个队列的长度。默认是128建议1000 三、慢查询日志 查看慢查询日志列表 slowlog len查询慢查询日志长度slowlog get[n]读取n条慢查询日志slowlog reset清空慢查询列表 四、排查步骤 查看slowlog慢日志 Redis 提供了慢日志命令的统计功能它记录了有哪些命令在执行时耗时比较久。
查看 Redis 慢日志之前你需要设置慢日志的阈值。例如设置慢日志的阈值为 5 毫秒并且保留最近 500 条慢日志记录
# 命令执行耗时超过 5 毫秒记录慢日志
CONFIG SET slowlog-log-slower-than 5000
# 只保留最近 500 条慢日志
CONFIG SET slowlog-max-len 500设置完成之后所有执行的命令如果操作耗时超过了 5 毫秒都会被 Redis 记录下来。
此时你可以执行以下命令就可以查询到最近记录的慢日志
127.0.0.1:6379 SLOWLOG get 5
1) 1) (integer) 32693 # 慢日志ID2) (integer) 1593763337 # 执行时间戳3) (integer) 5299 # 执行耗时(微秒)4) 1) LRANGE # 具体执行的命令和参数2) user_list:20003) 04) -1
2) 1) (integer) 326922) (integer) 15937633373) (integer) 50444) 1) GET2) user_info:1000通过查看慢日志我们就可以知道在什么时间点执行了哪些命令比较耗时。 五、Redis变慢原因 原因1使用复杂度过高的命令 排查思路
查看慢日志看是否有复杂度过高的命令。
导致变慢的操作 经常使用 O(N) 以上复杂度的命令例如 SORT、SUNION、ZUNIONSTORE 聚合类命令 原因Redis 在操作内存数据时时间复杂度过高要花费更多的 CPU 资源使用 O(N) 复杂度的命令但 N 的值非常大 原因Redis 一次需要返回给客户端的数据过多更多时间花费在数据协议的组装和网络传输过程中除此之外Redis 是单线程处理客户端请求的如果你经常使用以上命令那么当 Redis 处理客户端请求时一旦前面某个命令发生耗时就会导致后面的请求发生排队对于客户端来说响应延迟也会变长。 解决方案
尽量不使用 O(N) 以上复杂度过高的命令对于数据的聚合操作放在客户端做执行 O(N) 命令保证 N 尽量的小推荐 N 300每次获取尽量少的数据让 Redis 可以及时处理返回 原因2操作bigkeyvalue很大 排查思路
若你查询慢日志发现并不是复杂度过高的命令导致的而都是 SET / DEL 这种简单命令出现在慢日志中那么你就要怀疑你的实例否写入了 bigkey。
导致变慢的操作
Redis 在写入数据时需要为新的数据分配内存相对应的当从 Redis 中删除数据时它会释放对应的内存空间。如果一个 key 写入的 value 非常大那么 Redis 在分配内存时就会比较耗时。同样的当删除这个 key 时释放内存也会比较耗时这种类型的 key 我们一般称之为 bigkey。此时需要检查业务代码是否存在写入 bigkey 的情况。你需要评估写入一个 key 的数据大小尽量避免一个 key 存入过大的数据。
针对 bigkey 导致延迟的解决方案
业务应用尽量避免写入 bigkey将释放key的操作放到后台线程执行 Redis4.0 以上版本用 UNLINK 命令替代 DEL此命令可以把释放 key 内存的操作放到后台线程中去执行从而降低对 Redis 的影响Redis6.0 以上版本可以开启 lazy-free 机制lazyfree-lazy-user-del yes在执行 DEL 命令时释放内存也会放到后台线程中执行在此不建议在实例中存入 bigkey。这是因为 bigkey 在很多场景下依旧会产生性能问题。例如bigkey 在分片集群模式下对于数据的迁移也会有性能影响以及我后面即将讲到的数据过期、数据淘汰、透明大页都会受到 bigkey 的影响。 原因3集中过期 排查思路
如果你发现平时在操作 Redis 时并没有延迟很大的情况发生但在某个时间点突然出现一波延时其现象表现为变慢的时间点很有规律例如某个整点或者每间隔多久就会发生一波延迟。
如果是出现这种情况那么你需要排查一下业务代码中是否存在设置大量 key 集中过期的情况。
导致变慢的原因
如果有大量的 key 在某个固定时间点集中过期在这个时间点访问 Redis 时就有可能导致延时变大。
为什么集中过期会导致 Redis 延迟变大这就需要我们了解 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 是 4.0 以上版本可以开启 lazy-free 机制 这样当删除过期 key 时把释放内存的操作放到后台线程中执行避免阻塞主线程 集中过期 key 增加一个随机过期时间把集中过期的时间打散降低 Redis 清理过期 key 的压力
第1种方案 Redis 4.0 以上版本开启 lazy-free 机制
# 释放过期 key 的内存放到后台线程执行
lazyfree-lazy-expire yes第2种方案 在设置 key 的过期时间时增加一个随机时间伪代码可以这么写
# 在过期时间点之后的 5 分钟内随机过期掉
redis.expireat(key, expire_time random(300))Copy这样一来Redis 在处理过期时不会因为集中删除过多的 key 导致压力过大从而避免阻塞主线程。
文章如有不足之处欢迎大家在评论区指出进行讨论大家一起进步
