原文网址：Redis--变慢原因及排查方法_IT利刃出鞘的博客-CSDN博客

简介

说明

Redis速度是很快的，性能很高。但是，Redis有时候会存在执行很慢、性能很差的情况。本文介绍Redis为什么会变慢以及解决方案。

Redis执行命令流程

Redis是单线程操作,如果在Redis中执行耗时较长的操作,就会阻塞其他请求了。

Redis客户端执行一条命令，分为4部分：发送命令=>命令排队=> 命令执行=> 返回结果

慢查询在第三步，统计第三步执行时间。

排查步骤

第一步：确定Redis是否真的变慢了

排查思路

若发现你的业务服务 API 响应延迟变长，首先需要排查服务内部，究竟是哪个环节拖慢了整个服务。

比较高效的做法是，在服务内部集成链路追踪，也就是在服务访问外部依赖的出入口，记录下每次请求外部依赖的响应延时。若发现确实是操作 Redis 的这条链路耗时变长了，那么此刻你需要把焦点关注在业务服务到 Redis 这条链路上。

从你的业务服务到 Redis 这条链路变慢的原因可能也有 2 个：

  1. 业务服务器到 Redis 服务器之间的网络存在问题，例如网络线路质量不佳，网络数据包在传输时存在延迟、丢包等情况
  2. Redis 本身存在问题，需要进一步排查是什么原因导致 Redis 变慢

本文重点关注的是第二种情况。如何确认你的 Redis 是否真的变慢了？

基准性能

首先，你需要对 Redis 进行基准性能测试，了解你的 Redis 在生产环境服务器上的基准性能。

  • 基准性能就是指 Redis 在一台负载正常的机器上，其最大的响应延迟和平均响应延迟分别是怎样的。
  • 为什么要测试基准性能？我参考别人提供的响应延迟，判断自己的 Redis 是否变慢不行吗？
    • 答案是否定的。
    • 因为 Redis 在不同的软硬件环境下，它的性能是各不相同的。
      • 例如，我的机器配置比较低，当延迟为 2ms 时，我就认为 Redis 变慢了，但是如果你的硬件配置比较高，那么在你的运行环境下，可能延迟是 0.5ms 时就可以认为 Redis 变慢了。
      • 所以，你只有了解了你的 Redis 在生产环境服务器上的基准性能，才能进一步评估，当其延迟达到什么程度时，才认为 Redis 确实变慢了。

具体如何做？

为了避免业务服务器到 Redis 服务器之间的网络延迟，你需要直接在 Redis 服务器上测试实例的响应延迟情况。执行以下命令，就可以测试出这个实例 60 秒内的最大响应延迟：

$ redis-cli -h 127.0.0.1 -p 6379 --intrinsic-latency 60
Max latency so far: 1 microseconds.
Max latency so far: 15 microseconds.
Max latency so far: 17 microseconds.
Max latency so far: 18 microseconds.
Max latency so far: 31 microseconds.
Max latency so far: 32 microseconds.
Max latency so far: 59 microseconds.
Max latency so far: 72 microseconds.1428669267 total runs (avg latency: 0.0420 microseconds / 42.00 nanoseconds per run).
Worst run took 1429x longer than the average latency.

从输出结果可以看到，这 60 秒内的最大响应延迟为 72 微秒（0.072毫秒）。

你还可以使用以下命令，查看一段时间内 Redis 的最小、最大、平均访问延迟：

$ redis-cli -h 127.0.0.1 -p 6379 --latency-history -i 1
min: 0, max: 1, avg: 0.13 (100 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.12 (99 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.13 (99 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.10 (99 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.13 (98 samples) -- 1.00 seconds range
min: 0, max: 1, avg: 0.08 (99 samples) -- 1.01 seconds range
...

以上输出结果是，每间隔 1 秒，采样 Redis 的平均操作耗时，其结果分布在 0.08 ~ 0.13 毫秒之间。

了解了基准性能测试方法，那么你就可以按照以下几步，来判断你的 Redis 是否真的变慢了：

  • 在相同配置的服务器上，测试一个正常 Redis 实例的基准性能
  • 找到你认为可能变慢的 Redis 实例，测试这个实例的基准性能
  • 如果你观察到，这个实例的运行延迟是正常 Redis 基准性能的 2 倍以上，即可认为这个 Redis 实例确实变慢了

第二步：查看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:2000"3) "0"4) "-1"
2) 1) (integer) 326922) (integer) 15937633373) (integer) 50444) 1) "GET"2) "user_info:1000"
...

通过查看慢日志，我们就可以知道在什么时间点，执行了哪些命令比较耗时。

Redis变慢原因（Redis相关）

原因1：使用复杂度过高的命令

排查思路

查看慢日志，看是否有复杂度过高的命令。

导致变慢的操作

  1. 经常使用 O(N) 以上复杂度的命令，例如 SORT、SUNION、ZUNIONSTORE 聚合类命令

    1. 原因：Redis 在操作内存数据时，时间复杂度过高，要花费更多的 CPU 资源
  2. 使用 O(N) 复杂度的命令，但 N 的值非常大
    1. 原因：Redis 一次需要返回给客户端的数据过多，更多时间花费在数据协议的组装和网络传输过程中

另外，我们还可以从资源使用率层面来分析，如果你的应用程序操作 Redis 的 OPS 不是很大，但 Redis 实例的 CPU 使用率却很高，那么很有可能是使用了复杂度过高的命令导致的。

除此之外，Redis 是单线程处理客户端请求的，如果你经常使用以上命令，那么当 Redis 处理客户端请求时，一旦前面某个命令发生耗时，就会导致后面的请求发生排队，对于客户端来说，响应延迟也会变长。

解决方案

  1. 尽量不使用 O(N) 以上复杂度过高的命令，对于数据的聚合操作，放在客户端做
  2. 执行 O(N) 命令，保证 N 尽量的小（推荐 N <= 300），每次获取尽量少的数据，让 Redis 可以及时处理返回

原因2：操作bigkey（value很大）

排查思路

若你查询慢日志发现，并不是复杂度过高的命令导致的，而都是 SET / DEL 这种简单命令出现在慢日志中，那么你就要怀疑你的实例否写入了 bigkey。

导致变慢的操作

Redis 在写入数据时，需要为新的数据分配内存，相对应的，当从 Redis 中删除数据时，它会释放对应的内存空间。如果一个 key 写入的 value 非常大，那么 Redis 在分配内存时就会比较耗时。同样的，当删除这个 key 时，释放内存也会比较耗时，这种类型的 key 我们一般称之为 bigkey。此时，需要检查业务代码是否存在写入 bigkey 的情况。你需要评估写入一个 key 的数据大小，尽量避免一个 key 存入过大的数据。

找出bigkey 

若已经写入了 bigkey，可以扫描出实例中 bigkey 的分布情况吗？

答案是可以的。Redis 提供了扫描 bigkey 的命令，执行以下命令就可以扫描出，一个实例中 bigkey 的分布情况，输出结果是以类型维度展示的：

$ redis-cli -h 127.0.0.1 -p 6379 --bigkeys -i 0.01...
-------- summary -------Sampled 829675 keys in the keyspace!
Total key length in bytes is 10059825 (avg len 12.13)Biggest string found 'key:291880' has 10 bytes
Biggest   list found 'mylist:004' has 40 items
Biggest    set found 'myset:2386' has 38 members
Biggest   hash found 'myhash:3574' has 37 fields
Biggest   zset found 'myzset:2704' has 42 members36313 strings with 363130 bytes (04.38% of keys, avg size 10.00)
787393 lists with 896540 items (94.90% of keys, avg size 1.14)
1994 sets with 40052 members (00.24% of keys, avg size 20.09)
1990 hashs with 39632 fields (00.24% of keys, avg size 19.92)
1985 zsets with 39750 members (00.24% of keys, avg size 20.03)

输出结果我们可以很清晰地看到，每种数据类型所占用的最大内存 / 拥有最多元素的 key 是哪一个，以及每种数据类型在整个实例中的占比和平均大小 / 元素数量。

其实，使用这个命令的原理，就是 Redis 在内部执行了 SCAN 命令，遍历整个实例中所有的 key，然后针对 key 的类型，分别执行 STRLEN、LLEN、HLEN、SCARD、ZCARD 命令，来获取 String 类型的长度、容器类型（List、Hash、Set、ZSet）的元素个数。

执行这个命令时，要注意 2 个问题：

  1. 对线上实例进行 bigkey 扫描时，Redis 的 OPS 会突增，为了降低扫描过程中对 Redis 的影响，最好控制一下扫描的频率，指定 -i 参数即可，它表示扫描过程中每次扫描后休息的时间间隔，单位是秒
  2. 扫描结果中，对于容器类型（List、Hash、Set、ZSet）的 key，只能扫描出元素最多的 key。但一个 key 的元素多，不一定表示占用内存也多，你还需要根据业务情况，进一步评估内存占用情况

针对 bigkey 导致延迟的解决方案

  1. 业务应用尽量避免写入 bigkey
  2. 将释放key的操作放到后台线程执行
    1. Redis4.0 以上版本：用 UNLINK 命令替代 DEL，此命令可以把释放 key 内存的操作，放到后台线程中去执行，从而降低对 Redis 的影响
    2. Redis6.0 以上版本：可以开启 lazy-free 机制（lazyfree-lazy-user-del = yes），在执行 DEL 命令时，释放内存也会放到后台线程中执行

但即便可以使用方案 2，我也不建议你在实例中存入 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 上，这种情况我们需要尤为注意。

解决方案

  1. 如果你使用的 Redis 是 4.0 以上版本，可以开启 lazy-free 机制

    1. 这样当删除过期 key 时，把释放内存的操作放到后台线程中执行，避免阻塞主线程
  2. 集中过期 key 增加一个随机过期时间，把集中过期的时间打散，降低 Redis 清理过期 key 的压力

第1种方案

Redis 4.0 以上版本，开启 lazy-free 机制：

# 释放过期 key 的内存，放到后台线程执行
lazyfree-lazy-expire yes

第2种方案

在设置 key 的过期时间时，增加一个随机时间，伪代码可以这么写：

# 在过期时间点之后的 5 分钟内随机过期掉
redis.expireat(key, expire_time + random(300))

这样一来，Redis 在处理过期时，不会因为集中删除过多的 key 导致压力过大，从而避免阻塞主线程。

运维层面

另外，除了业务层面的优化和修改配置之外，你还可以通过运维手段及时发现这种情况。

运维层面，你需要把 Redis 的各项运行状态数据监控起来，在 Redis 上执行 INFO 命令就可以拿到这个实例所有的运行状态数据。

在这里我们需要重点关注 expired_keys 这一项，它代表整个实例到目前为止，累计删除过期 key 的数量。

你需要把这个指标监控起来，当这个指标在很短时间内出现了突增，需要及时报警出来，然后与业务应用报慢的时间点进行对比分析，确认时间是否一致，如果一致，则可以确认确实是因为集中过期 key 导致的延迟变大。

原因4：开启AOF

简介

当 Redis 开启 AOF 后，其工作原理如下：

  1. Redis 执行写命令后，把这个命令写入到 AOF 内存中（write 系统调用）
  2. Redis 根据配置的 AOF 刷盘策略，把 AOF 内存数据刷到磁盘上（fsync 系统调用）

为了保证 AOF 文件数据的安全性，Redis 提供了 3 种刷盘机制：

  1. appendfsync everysec（默认）

    1. 主线程每次写操作只写内存就返回，然后由后台线程每隔 1 秒执行一次刷盘操作（触发fsync系统调用）
    2. 此方案对性能影响相对较小，但当 Redis 宕机时会丢失 1 秒的数据
  2. appendfsync always
    1. 主线程每次执行写操作后立即刷盘
    2. 此方案会占用比较大的磁盘 IO 资源，但数据安全性最高
  3. appendfsync no
    1. 主线程每次写操作只写内存就返回，内存数据什么时候刷到磁盘，交由操作系统决定
    2. 方案对性能影响最小，但数据安全性也最低，Redis 宕机时丢失的数据取决于操作系统刷盘时机。

导致变慢的原因

依次来分析，这几个机制对性能的影响。

appendfsync always

  • Redis 每处理一次写操作，都会把这个命令写入到磁盘中才返回，整个过程都是在主线程执行的，这个过程必然会加重 Redis 写负担。
  • 原因也很简单，操作磁盘要比操作内存慢几百倍，采用这个配置会严重拖慢 Redis 的性能，因此我不建议你把 AOF 刷盘方式配置为 always。

appendfsync no

  • Redis 每次写操作只写内存，什么时候把内存中的数据刷到磁盘，交给操作系统决定，此方案对 Redis 的性能影响最小，但当 Redis 宕机时，会丢失一部分数据。

appendfsync everysec

  • Redis 主线程写完内存后就返回，具体的刷盘操作是放到后台线程中执行的，后台线程每隔 1 秒把内存中的数据刷到磁盘中。兼顾了性能又尽可能地保证数据安全，是不是觉得很完美？
  • 这种方案还是存在导致 Redis 延迟变大的情况发生，甚至会阻塞整个 Redis。
    • 为什么？我把 AOF 最耗时的刷盘操作，放到后台线程中也会影响到 Redis 主线程？

      • 当 Redis 后台线程在执行 AOF 文件刷盘时，如果此时磁盘的 IO 负载很高，那这个后台线程在执行刷盘操作（fsync系统调用）时就会被阻塞住。

      • 此时的主线程依旧会接收写请求，紧接着，主线程又需要把数据写到文件内存中（write 系统调用），但此时的后台子线程由于磁盘负载过高，导致 fsync 发生阻塞，迟迟不能返回，此时因为内存没剩余空间，那主线程在执行 write 系统调用时，也会被阻塞住，直到后台线程 fsync 执行完成后，主线程执行 write 才能成功返回。

解决方案

什么情况下会导致磁盘 IO 负载过大？以及如何解决这个问题呢？

我总结了以下几种情况，你可以参考进行问题排查：

  1. 子进程正在执行 AOF rewrite，这个过程会占用大量的磁盘 IO 资源
  2. 有其他应用程序在执行大量的写文件操作，也会占用磁盘 IO 资源

对于情况1，Redis 的 AOF 后台子线程刷盘操作，撞上了子进程 AOF rewrite

这怎么办？难道要关闭 AOF rewrite 才行？

幸运的是，Redis 提供了一个配置项，当子进程在 AOF rewrite 期间，可以让后台子线程不执行刷盘（不触发 fsync 系统调用）操作。这相当于在 AOF rewrite 期间，临时把 appendfsync 设置为了 none，配置如下：

# AOF rewrite 期间，AOF 后台子线程不进行刷盘操作
# 相当于在这期间，临时把 appendfsync 设置为了 none
no-appendfsync-on-rewrite yes

当然，开启这个配置项，在 AOF rewrite 期间，如果实例发生宕机，那么此时会丢失更多的数据，性能和数据安全性，你需要权衡后进行选择。

对于情况2：占用磁盘资源的是其他应用程序

那就比较简单了，你需要定位到是哪个应用程序在大量写磁盘，然后把这个应用程序迁移到其他机器上执行就好了，避免对 Redis 产生影响。

当然，如果你对 Redis 的性能和数据安全都有很高的要求，那么我建议从硬件层面来优化，更换为 SSD 磁盘，提高磁盘的 IO 能力，保证 AOF 期间有充足的磁盘资源可以使用。

原因5：fork耗时严重

排查思路

为了保证 Redis 数据的安全性，我们可能会开启后台定时 RDB 和 AOF rewrite 功能。

如果你发现操作 Redis 延迟变大，都发生在 Redis 后台 RDB 和 AOF rewrite 期间，那你就需要排查，在这期间有可能导致变慢的情况。

导致变慢的原因

  • 当 Redis 开启了后台 RDB 和 AOF rewrite 后，在执行时，它们都需要主进程创建出一个子进程进行数据的持久化。主进程创建子进程，会调用操作系统提供的 fork 函数。
  • 而 fork 在执行过程中，主进程需要拷贝自己的内存页表给子进程，如果这个实例很大，那么这个拷贝的过程也会比较耗时。
  • 而且这个 fork 过程会消耗大量的 CPU 资源，在完成 fork 之前，整个 Redis 实例会被阻塞住，无法处理任何客户端请求。
  • 如果此时你的 CPU 资源本来就很紧张，那么 fork 的耗时会更长，甚至达到秒级，这会严重影响 Redis 的性能。

如何确认是因为 fork 耗时导致的 Redis 延迟变大呢？你可以在 Redis 上执行 INFO 命令，查看 latest_fork_usec 项，单位微秒。

# 上一次 fork 耗时，单位微秒
latest_fork_usec:59477

这个时间就是主进程在 fork 子进程期间，整个实例阻塞无法处理客户端请求的时间。

如果你发现这个耗时很久，就要警惕起来了，这意味在这期间，你的整个 Redis 实例都处于不可用的状态。

除了数据持久化会生成 RDB 之外，当主从节点第一次建立数据同步时，主节点也创建子进程生成 RDB，然后发给从节点进行一次全量同步，所以，这个过程也会对 Redis 产生性能影响。

 解决方案

  1. 控制 Redis 实例的内存：尽量在 10G 以下，执行 fork 的耗时与实例大小有关，实例越大，耗时越久
  2. 合理配置数据持久化策略：在 slave 节点执行 RDB 备份，推荐在低峰期执行，而对于丢失数据不敏感的业务（例如把 Redis 当做纯缓存使用），可以关闭 AOF 和 AOF rewrite
  3. Redis 实例不要部署在虚拟机上：fork 的耗时也与系统也有关，虚拟机比物理机耗时更久
  4. 降低主从库全量同步的概率：适当调大 repl-backlog-size 参数，避免主从全量同步

原因6：碎片整理

简介

Redis 的数据都存储在内存中，当我们的应用程序频繁修改 Redis 中的数据时，就有可能会导致 Redis 产生内存碎片。

内存碎片会降低 Redis 的内存使用率，我们可以通过执行 INFO 命令，得到这个实例的内存碎片率：

# Memory
used_memory:5709194824
used_memory_human:5.32G
used_memory_rss:8264855552
used_memory_rss_human:7.70G
...
mem_fragmentation_ratio:1.45

这个内存碎片率是怎么计算的？

很简单，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 版本，它正好提供了自动碎片整理的功能，可以通过配置开启碎片自动整理

导致变慢的原因

Redis 的碎片整理工作是也在主线程中执行的，当其进行碎片整理时，必然会消耗 CPU 资源，产生更多的耗时，从而影响到客户端的请求。

Redis 碎片整理的参数配置如下：

# 开启自动内存碎片整理（总开关）
activedefrag yes# 内存使用 100MB 以下，不进行碎片整理
active-defrag-ignore-bytes 100mb# 内存碎片率超过 10%，开始碎片整理
active-defrag-threshold-lower 10
# 内存碎片率超过 100%，尽最大努力碎片整理
active-defrag-threshold-upper 100# 内存碎片整理占用 CPU 资源最小百分比
active-defrag-cycle-min 1
# 内存碎片整理占用 CPU 资源最大百分比
active-defrag-cycle-max 25# 碎片整理期间，对于 List/Set/Hash/ZSet 类型元素一次 Scan 的数量
active-defrag-max-scan-fields 1000

解决方案

结合 Redis 机器的负载情况，以及应用程序可接受的延迟范围进行评估，合理调整碎片整理的参数，尽可能降低碎片整理期间对 Redis 的影响。

原因7：绑定CPU

简介

很多时候，我们在部署服务时，为了提高服务性能，降低应用程序在多个 CPU 核心之间的上下文切换带来的性能损耗，通常采用的方案是进程绑定 CPU 的方式提高性能。

导致变慢的原因

在部署 Redis 时，如果你需要绑定 CPU 来提高其性能，我建议你仔细斟酌后再做操作。为什么？

因为 Redis 在绑定 CPU 时，是有很多考究的，如果你不了解 Redis 的运行原理，随意绑定 CPU 不仅不会提高性能，甚至有可能会带来相反的效果。

我们都知道，一般现代的服务器会有多个 CPU，而每个 CPU 又包含多个物理核心，每个物理核心又分为多个逻辑核心，每个物理核下的逻辑核共用 L1/L2 Cache。

而 Redis Server 除了主线程服务客户端请求之外，还会创建子进程、子线程。其中子进程用于数据持久化，而子线程用于执行一些比较耗时操作，例如异步释放 fd、异步 AOF 刷盘、异步 lazy-free 等等。如果你把 Redis 进程只绑定了一个 CPU 逻辑核心上，那么当 Redis 在进行数据持久化时，fork 出的子进程会继承父进程的 CPU 使用偏好。而此时的子进程会消耗大量的 CPU 资源进行数据持久化（把实例数据全部扫描出来需要耗费CPU），这就会导致子进程会与主进程发生 CPU 争抢，进而影响到主进程服务客户端请求，访问延迟变大。这就是 Redis 绑定 CPU 带来的性能问题。

解决方案

  • 如果你确实想要绑定 CPU，可以优化的方案是，不要让 Redis 进程只绑定在一个 CPU 逻辑核上，而是绑定在多个逻辑核心上，而且，绑定的多个逻辑核心最好是同一个物理核心，这样它们还可以共用 L1/L2 Cache。
  • 当然，即便我们把 Redis 绑定在多个逻辑核心上，也只能在一定程度上缓解主线程、子进程、后台线程在 CPU 资源上的竞争。因为这些子进程、子线程还是会在这多个逻辑核心上进行切换，存在性能损耗。
  • 如何再进一步优化？可能你已经想到了，我们是否可以让主线程、子进程、后台线程，分别绑定在固定的 CPU 核心上，不让它们来回切换，这样一来，他们各自使用的 CPU 资源互不影响。
  • 其实，这个方案 Redis 官方已经想到了。Redis 在 6.0 版本已经推出了这个功能，我们可以通过以下配置，对主线程、后台线程、后台 RDB 进程、AOF rewrite 进程，绑定固定的 CPU 逻辑核心：
# Redis Server 和 IO 线程绑定到 CPU核心 0,2,4,6
server_cpulist 0-7:2# 后台子线程绑定到 CPU核心 1,3
bio_cpulist 1,3# 后台 AOF rewrite 进程绑定到 CPU 核心 8,9,10,11
aof_rewrite_cpulist 8-11# 后台 RDB 进程绑定到 CPU 核心 1,10,11
# bgsave_cpulist 1,10-1

如果你使用的正好是 Redis 6.0 版本，就可以通过以上配置，来进一步提高 Redis 性能。

这里我需要提醒你的是，一般来说，Redis 的性能已经足够优秀，除非你对 Redis 的性能有更加严苛的要求，否则不建议你绑定 CPU。

Redis变慢原因（系统相关）

见：Redis--变慢的原因及排查方法--系统方面_IT利刃出鞘的博客-CSDN博客

其他网址

Redis为什么变慢了？一文讲透如何排查Redis性能问题 | 万字长文_Java笔记虾-CSDN博客
Redis变慢原因_狼行千里吃肉-CSDN博客

Redis性能问题排查解决手册(七) - 蘑菇先生 - 博客园
注意！!Redis使用不当真的可能会导致应用卡死 - 知乎

另见《Redis开发与运维》=> 3.3 Pipeline

Redis--变慢原因及排查方法相关推荐

  1. Redis--变慢的原因及排查方法--系统方面

    原文网址:Redis--变慢的原因及排查方法--系统方面_IT利刃出鞘的博客-CSDN博客 简介 说明 本文介绍Redis变慢的系统方面的原因. 相关网址 Redis变慢的本身原因见:Redis--变 ...

  2. java内存溢出 栈溢出的原因与排查方法

    java内存溢出 原因与排查方法 1. 内存溢出的原因是什么? 内存溢出是由于没被引用的对象(垃圾)过多造成JVM没有及时回收,导致剩余的内存不够用,造成的内存溢出.如果出现这种现象可行代码排查: 一 ...

  3. 域名解析不生效的原因和排查方法

    域名解析不生效的原因和排查方法 常见的影响域名解析生效的原因有: 域名状态异常:域名已到期:域名解析刚修改过dns或解析 一.域名状态异常导致的解析无法生效: 在whois查询(​ ​whois.22 ...

  4. redis变慢原因记录

    有时候会遇到这种场景: 当调用程序的某个接口时,发现这个接口响应速度很慢,首先要排查慢在哪个环节?如下图: 排查环节大致有这么几个: 后端业务代码,是不是在某个地方出现了长时间的循环.等待临界资源等等 ...

  5. win10开机慢怎么解决_电脑开机速度慢怎么解决？Win10电脑开机速度变慢原因及解决方法...

    如今买电脑,我们都会首选固态硬盘,固态硬盘相比机械硬盘最大的好处就是读写速度快,尤其是电脑开机的时候,系统安装在固态硬盘正常需要10秒左右就可以成功进入桌面,而机械硬盘正常至少30-40秒左右才可以进 ...

  6. 网站打开速度慢的原因，排查方法及优化方法（大全）

    如果你的网站打开速度过慢,而你又不知道该如何解决,那么这篇文章是非看不可了.手把手的教你如何排查网站打开慢的原因,以及优化方法. 排查网站打开速度慢的原因: 1网站服务器速度或租用空间所在服务器速度 ...

  7. 超详细分析Windows变慢原因及解决方法

    谁都希望计算机一开机就可以立即进入Windows 系统而不用等待,或者是系统在使用的时候不会越来越慢,但由于种种原因常常使这些愿望不能实现,甚至一开机就死机或者用着用着就越来越慢的情况也经常发生.其实 ...

  8. 【Java面试】Java 内存溢出 栈溢出的原因与排查方法

    1. 内存溢出的原因是什么? 内存溢出是由于没被引用的对象(垃圾)过多造成JVM没有及时回收,造成的内存溢出.如果出现这种现象可行代码排查: 一)是否App中的类中和引用变量过多使用了Static修饰 ...

  9. linux 内存溢出排查_java 内存溢出 栈溢出的原因与排查方法

    1. 内存溢出的原因是什么? 内存溢出是由于没被引用的对象(垃圾)过多造成JVM没有及时回收,造成的内存溢出.如果出现这种现象可行代码排查: 一)是否应用中的类中和引用变量过多使用了Static修饰 ...

最新文章

  1. python os.path 模块 路径文件名 新建文件夹 文件 路径 是否存在
  2. log4j配置及正确使用方式
  3. 内核态与用户态的区别
  4. SQL 2005 收缩事务日志文件
  5. View结合组策略进行应用程序下发
  6. 停止Hadoop或HBase集群的脚本
  7. Prepare for Mac App Store Submission--为提交到Mac 应用商店做准备
  8. python槽格式里填啥_用于填充插槽的网络挂钩
  9. 条件语句的多层嵌套问题优化，助你写出不让同事吐槽的代码
  10. php写进度条原理,php实现进度条原理
  11. 1067. Sort with Swap(0,*)
  12. NIOS II 烧写epcs总结
  13. 初中英语语法(011)-形容词
  14. android ipv6测试,搭建IPv6本地环境测试App
  15. 连入网络中的计算机必须都是,12计算机网络判断题.doc
  16. 遥感智能解译相关产品及公司
  17. 基于贝叶斯分类器的手写字判别
  18. C++ 实验十四结构程序设计
  19. UE4人物移动时的摄像机抖动
  20. 上海市计算机一级考试试题模拟,48-上海市高校计算机等级考试一级 模拟试题...

热门文章

  1. 回顾历史“312”，展望未来牛市
  2. 思维导图怎么画？分享中考学习计划思维导图模板及绘制技巧
  3. android7.1.2彩蛋,在Android 7.0牛轧糖中解锁秘密猫收集复活节彩蛋 | MOS86
  4. 路由器的密码破解方法（实用篇）
  5. intelliJ IDEA什么意思
  6. 白话详解ROCAUC | 小白深度学习入门
  7. groovy逆向工程生成自定义实体类图文详解
  8. MongoDB数据库基本操作
  9. 六核至强处理器E5系列服务器CPU,至强E3、E5、E7服务器处理器型号的含义
  10. 使用爬虫爬取豆瓣电影影评数据Java版