Redis가 갑자기 느려지나요? Redis에 성능 문제가 있는지 판단하는 방법과 해결 방법을 분석해 보겠습니다.

이 글은 Redis에 대한 관련 지식을 제공합니다. Redis의 과도한 지연은 다양한 문제를 일으킬 수 있습니다. Redis에 성능 문제가 있는지 확인하는 방법과 해결 방법이 모두에게 도움이 되기를 바랍니다.

추천 학습: Redis 튜토리얼

Redis는 일반적으로 캐시, 계정 로그인 정보, 순위 등과 같은 비즈니스 시스템의 중요한 구성 요소입니다.

Redis 요청 지연이 증가하면 비즈니스 시스템에 "사태"가 발생할 수 있습니다.

저는 중매형 인터넷 회사에 근무하고 있습니다. 더블일레븐 시절 주문하면 여자친구에게 선물을 주는 캠페인을 펼쳤습니다.

오전 12시 이후에 이용자가 급격하게 늘어나는데, 기술적 결함으로 인해 이용자가 주문을 할 수 없게 될 줄 누가 알았겠습니까!

검색 결과 Redis가 풀에서 리소스를 가져올 수 없습니다라고 보고한 것을 발견했습니다. Could not get a resource from the pool。

获取不到连接资源，并且集群中的单台 Redis 连接量很高。

大量的流量没了 Redis 的缓存响应，直接打到了 MySQL，最后数据库也宕机了……

于是各种更改最大连接数、连接等待数，虽然报错信息频率有所缓解，但还是持续报错。

后来经过线下测试，发现存放 Redis 中的字符数据很大，平均 1s 返回数据。

可以发现，一旦 Redis 延迟过高，会引发各种问题。

今天跟大家一起来分析下如何确定 Redis 有性能问题和解决方案。

Redis 性能出问题了么？

最大延迟是客户端发出命令到客户端收到命令的响应的时间，正常情况下 Redis 处理的时间极短，在微秒级别。

当 Redis 出现性能波动的时候，比如达到几秒到十几秒，这个很明显我们可以认定 Redis 性能变慢了。

有的硬件配置比较高，当延迟 0.6ms，我们可能就认定变慢了。硬件比较差的可能 3 ms 我们才认为出现问题。

那我们该如何定义 Redis 真的变慢了呢？

所以，我们需要对当前环境的 Redis 基线性能做测量，也就是在一个系统在低压力、无干扰情况下的基本性能。

当你发现 Redis 运行时时的延迟是基线性能的 2 倍以上，就可以判定 Redis 性能变慢了。

延迟基线测量

redis-cli 命令提供了–intrinsic-latency 选项，用来监测和统计测试期间内的最大延迟（以毫秒为单位），这个延迟可以作为 Redis 的基线性能。

redis-cli --latency -h `host` -p `port`

比如执行如下指令：

redis-cli --intrinsic-latency 100
Max latency so far: 4 microseconds.
Max latency so far: 18 microseconds.
Max latency so far: 41 microseconds.
Max latency so far: 57 microseconds.
Max latency so far: 78 microseconds.
Max latency so far: 170 microseconds.
Max latency so far: 342 microseconds.
Max latency so far: 3079 microseconds.
45026981 total runs (avg latency: 2.2209 microseconds / 2220.89 nanoseconds per run).
Worst run took 1386x longer than the average latency.

注意：参数100是测试将执行的秒数。我们运行测试的时间越长，我们就越有可能发现延迟峰值。

通常运行 100 秒通常是合适的，足以发现延迟问题了，当然我们可以选择不同时间运行几次，避免误差。

运行的最大延迟是 3079 微秒，所以基线性能是 3079 （3 毫秒）微秒。

需要注意的是，我们要在 Redis 的服务端运行，而不是客户端。这样，可以避免网络对基线性能的影响。

可以通过 -h host -p port 

연결 리소스를 얻을 수 없으며 클러스터의 단일 Redis에 대한 연결 수가 매우 높습니다.

대량의 트래픽이 Redis의 캐시된 응답을 잃어버리고 MySQL을 직접 공격하게 되면서 결국 데이터베이스도 다운되었습니다...

그래서 최대 연결 수와 연결 대기 수에 다양한 변경이 이루어졌습니다. 오류 메시지의 빈도가 완화되었음에도 불구하고 오류는 계속 발생합니다.

나중에 오프라인 테스트 결과 Redis에 저장된 문자 데이터가 매우 크고, 평균 1초 안에 데이터가 반환되는 것으로 나타났습니다.

Redis의 지연 시간이 너무 높으면 다양한 문제가 발생하는 것을 확인할 수 있습니다.

오늘은 Redis에 성능 문제가 있는지 판단하는 방법과 해결 방법을 함께 분석해 보겠습니다.

Redis 성능에 문제는 없나요?

최대 지연은 클라이언트가 명령을 내리는 시점부터 명령에 대한 응답을 받는 클라이언트까지의 시간입니다. 일반적인 상황에서 Redis의 처리 시간은 마이크로초 수준으로 매우 짧습니다.

Redis의 성능이 변동하는 경우, 예를 들어 몇 초에서 10초 이상에 도달하면 Redis의 성능이 느려졌다고 결론을 내릴 수 있음은 자명합니다.

일부 하드웨어 구성은 상대적으로 지연 시간이 0.6ms일 때 느린 것으로 간주할 수 있습니다. 하드웨어가 상대적으로 열악한 경우 문제가 있다고 판단하는 데 3ms가 걸릴 수 있습니다.

• 그러면 Redis가 정말 느린지 어떻게 정의해야 할까요?

• 그래서 우리는 현재 환경의 Redis 기준 성능, 즉 저압 및 무간섭 환경에서 시스템의 기본 성능을 측정해야 합니다.
  Redis 런타임의 지연 시간이 기준 성능의 2배 이상인 것을 발견하면 Redis 성능이 느려졌다고 판단할 수 있습니다.

지연 기준 측정

redis-cli 명령은 테스트 중 모니터링 및 통계를 위한 –intrinsic-latency 옵션을 제공합니다. 최대 지연 (밀리초 단위) 시간 제한 내에서 Redis의 기본 성능으로 사용할 수 있습니다. 🎜

redis-cli CONFIG SET slowlog-log-slower-than 6000

🎜예를 들어 다음 명령을 실행합니다. 🎜

127.0.0.1:6381> SLOWLOG get 2
1) 1) (integer) 6
   2) (integer) 1458734263
   3) (integer) 74372
   4) 1) "hgetall"
      2) "max.dsp.blacklist"
2) 1) (integer) 5
   2) (integer) 1458734258
   3) (integer) 5411075
   4) 1) "keys"
      2) "max.dsp.blacklist"

🎜🎜참고: 매개변수 100은 테스트가 실행되는 시간(초)입니다. 테스트를 오래 실행할수록 지연 시간 급증을 발견할 가능성이 높아집니다. 🎜🎜보통 100초 동안 실행하는 것이 적절하며, 이는 대기 시간 문제를 감지하기에 충분합니다. 물론 오류를 피하기 위해 서로 다른 시간에 여러 번 실행하도록 선택할 수도 있습니다. 🎜🎜🎜실행 중인 최대 대기 시간은 3079마이크로초이므로 기본 성능은 3079(3밀리초)마이크로초입니다. 🎜🎜클라이언트가 아닌 Redis 서버에서 실행해야 한다는 점에 유의하세요. 이러한 방식으로 기본 성능에 대한 네트워크 영향을 피할 수 있습니다. 🎜🎜 -h 호스트 -p 포트 를 통해 서버에 연결할 수 있습니다. 네트워크가 Redis 성능에 미치는 영향을 모니터링하려면 Iperf를 사용하여 클라이언트에서 네트워크 지연을 측정할 수 있습니다. 서버. 🎜🎜네트워크가 수백 밀리초 동안 지연되면 네트워크에서 트래픽이 많은 다른 프로그램이 실행되어 네트워크 정체가 발생할 수 있음을 의미하므로 네트워크의 트래픽 분산을 조정하기 위한 운영 및 유지 관리가 필요합니다. 🎜🎜느린 명령 모니터링🎜🎜🎜느린 명령인지 어떻게 판단하나요? 🎜🎜🎜연산 복잡도가 O(N)인지 확인하세요. 공식 문서에서는 가능한 한 O(1) 및 O(log N) 명령을 사용하여 각 명령의 복잡성을 소개합니다. 🎜🎜전체 집합 쿼리 HGETALL, SMEMBERS 및 집합 집계 작업(SORT, LREM, SUNION 등)과 같은 집합 작업과 관련된 복잡성은 일반적으로 O(N)입니다. 🎜🎜🎜관찰할 수 있는 모니터링 데이터가 있나요? 나는 코드를 작성하지 않았습니다. 누군가가 느린 명령을 사용했는지는 모르겠습니다. 🎜🎜🎜문제를 해결하는 방법에는 두 가지가 있습니다. 🎜🎜🎜🎜Redis 느린 로그 기능을 사용하여 느린 명령을 감지합니다. 🎜🎜🎜🎜latency-monitor(대기 시간 모니터링) 도구. 🎜🎜🎜🎜또한 자신(top, htop, prstat 등)을 사용하여 Redis 메인 프로세스의 CPU 사용량을 빠르게 확인할 수 있습니다. CPU 사용량은 높지만 트래픽이 낮다면 일반적으로 느린 명령이 사용되고 있음을 나타냅니다. 🎜

慢日志功能

Redis 中的 slowlog 命令可以让我们快速定位到那些超出指定执行时间的慢命令，默认情况下命令若是执行时间超过 10ms 就会被记录到日志。

slowlog 只会记录其命令执行的时间，不包含 io 往返操作，也不记录单由网络延迟引起的响应慢。

我们可以根据基线性能来自定义慢命令的标准（配置成基线性能最大延迟的 2 倍），调整触发记录慢命令的阈值。

可以在 redis-cli 中输入以下命令配置记录 6 毫秒以上的指令：

redis-cli CONFIG SET slowlog-log-slower-than 6000

也可以在 Redis.config 配置文件中设置，以微秒为单位。

想要查看所有执行时间比较慢的命令，可以通过使用 Redis-cli 工具，输入 slowlog get 命令查看，返回结果的第三个字段以微秒位单位显示命令的执行时间。

假如只需要查看最后 2 个慢命令，输入 slowlog get 2 即可。

示例：获取最近2个慢查询命令

127.0.0.1:6381> SLOWLOG get 2
1) 1) (integer) 6
   2) (integer) 1458734263
   3) (integer) 74372
   4) 1) "hgetall"
      2) "max.dsp.blacklist"
2) 1) (integer) 5
   2) (integer) 1458734258
   3) (integer) 5411075
   4) 1) "keys"
      2) "max.dsp.blacklist"

以第一个 HGET 命令为例分析，每个 slowlog 实体共 4 个字段：

• 字段 1：1 个整数，表示这个 slowlog 出现的序号，server 启动后递增，当前为 6。

• 字段 2：表示查询执行时的 Unix 时间戳。

• 字段 3：表示查询执行微秒数,当前是 74372 微秒,约 74ms。

• 字段 4: 表示查询的命令和参数,如果参数很多或很大,只会显示部分参数个数。当前命令是hgetall max.dsp.blacklist。

Latency Monitoring

Redis 在 2.8.13 版本引入了 Latency Monitoring 功能，用于以秒为粒度监控各种事件的发生频率。

启用延迟监视器的第一步是设置延迟阈值(单位毫秒)。只有超过该阈值的时间才会被记录，比如我们根据基线性能（3ms）的 3 倍设置阈值为 9 ms。

可以用 redis-cli 设置也可以在 Redis.config 中设置；

CONFIG SET latency-monitor-threshold 9

工具记录的相关事件的详情可查看官方文档：https://redis.io/topics/latency-monitor

如获取最近的 latency

127.0.0.1:6379> debug sleep 2
OK
(2.00s)
127.0.0.1:6379> latency latest
1) 1) "command"
   2) (integer) 1645330616
   3) (integer) 2003
   4) (integer) 2003

事件的名称；

事件发生的最新延迟的 Unix 时间戳；

毫秒为单位的时间延迟；

该事件的最大延迟。

如何解决 Redis 变慢？

Redis 的数据读写由单线程执行，如果主线程执行的操作时间太长，就会导致主线程阻塞。

一起分析下都有哪些操作会阻塞主线程，我们又该如何解决？

网络通信导致的延迟

客户端使用 TCP/IP 连接或 Unix 域连接连接到 Redis。1 Gbit/s 网络的典型延迟约为 200 us。

redis 客户端执行一条命令分 4 个过程：

发送命令－〉 命令排队 －〉 命令执行－〉 返回结果

这个过程称为 Round trip time(简称 RTT, 往返时间)，mget mset 有效节约了 RTT，但大部分命令（如 hgetall，并没有 mhgetall）不支持批量操作，需要消耗 N 次 RTT ，这个时候需要 pipeline 来解决这个问题。

Redis pipeline 将多个命令连接在一起来减少网络响应往返次数。

redis-pipeline

慢指令导致的延迟

根据上文的慢指令监控查询文档，查询到慢查询指令。可以通过以下两种方式解决：

比如在 Cluster 集群中，将聚合运算等 O(N) 操作运行在 slave 上，或者在客户端完成。

使用高效的命令代替。使用增量迭代的方式，避免一次查询大量数据，具体请查看SCAN、SSCAN、HSCAN和ZSCAN命令。

除此之外，生产中禁用KEYS 命令，它只适用于调试。因为它会遍历所有的键值对，所以操作延时高。

Fork 生成 RDB 导致的延迟

生成 RDB 快照，Redis 必须 fork 后台进程。fork 操作（在主线程中运行）本身会导致延迟。

Redis 使用操作系统的多进程写时复制技术 COW(Copy On Write) 来实现快照持久化，减少内存占用。

写时复制技术保证快照期间数据可修改

但 fork 会涉及到复制大量链接对象，一个 24 GB 的大型 Redis 实例需要 24 GB / 4 kB * 8 = 48 MB 的页表。

执行 bgsave 时，这将涉及分配和复制 48 MB 内存。

此外，从库加载 RDB 期间无法提供读写服务，所以主库的数据量大小控制在 2~4G 左右，让从库快速的加载完成。

内存大页（transparent huge pages）

常规的内存页是按照 4 KB 来分配，Linux 内核从 2.6.38 开始支持内存大页机制，该机制支持 2MB 大小的内存页分配。

Redis 使用了 fork 生成 RDB 做持久化提供了数据可靠性保证。

当生成 RDB 快照的过程中，Redis 采用**写时复制**技术使得主线程依然可以接收客户端的写请求。

也就是当数据被修改的时候，Redis 会复制一份这个数据，再进行修改。

采用了内存大页，生成 RDB 期间，即使客户端修改的数据只有 50B 的数据，Redis 需要复制 2MB 的大页。当写的指令比较多的时候就会导致大量的拷贝，导致性能变慢。

使用以下指令禁用 Linux 内存大页即可：

echo never > /sys/kernel/mm/transparent_hugepage/enabled

swap：操作系统分页

当物理内存（内存条）不够用的时候，将部分内存上的数据交换到 swap 空间上，以便让系统不会因内存不够用而导致 oom 或者更致命的情况出现。

当某进程向 OS 请求内存发现不足时，OS 会把内存中暂时不用的数据交换出去，放在 SWAP 分区中，这个过程称为 SWAP OUT。

当某进程又需要这些数据且 OS 发现还有空闲物理内存时，又会把 SWAP 分区中的数据交换回物理内存中，这个过程称为 SWAP IN。

内存 swap 是操作系统里将内存数据在内存和磁盘间来回换入和换出的机制，涉及到磁盘的读写。

触发 swap 的情况有哪些呢？

对于 Redis 而言，有两种常见的情况：

Redis 使用了比可用内存更多的内存；

与 Redis 在同一机器运行的其他进程在执行大量的文件读写 I/O 操作（包括生成大文件的 RDB 文件和 AOF 后台线程），文件读写占用内存，导致 Redis 获得的内存减少，触发了 swap。

我要如何排查是否因为 swap 导致的性能变慢呢？

Linux 提供了很好的工具来排查这个问题，所以当怀疑由于交换导致的延迟时，只需按照以下步骤排查。

获取 Redis 实例 pid

$ redis-cli info | grep process_id
process_id:13160

进入此进程的 /proc 文件系统目录：

cd /proc/13160

在这里有一个 smaps 的文件，该文件描述了 Redis 进程的内存布局，运行以下指令，用 grep 查找所有文件中的 Swap 字段。

$ cat smaps | egrep '^(Swap|Size)'
Size:                316 kB
Swap:                  0 kB
Size:                  4 kB
Swap:                  0 kB
Size:                  8 kB
Swap:                  0 kB
Size:                 40 kB
Swap:                  0 kB
Size:                132 kB
Swap:                  0 kB
Size:             720896 kB
Swap:                 12 kB

每行 Size 表示 Redis 实例所用的一块内存大小，和 Size 下方的 Swap 对应这块 Size 大小的内存区域有多少数据已经被换出到磁盘上了。

如果 Size == Swap 则说明数据被完全换出了。

可以看到有一个 720896 kB 的内存大小有 12 kb 被换出到了磁盘上（仅交换了 12 kB），这就没什么问题。

Redis 本身会使用很多大小不一的内存块，所以，你可以看到有很多 Size 行，有的很小，就是 4KB，而有的很大，例如 720896KB。不同内存块被换出到磁盘上的大小也不一样。

敲重点了

如果 Swap 一切都是 0 kb，或者零星的 4k ，那么一切正常。

当出现百 MB，甚至 GB 级别的 swap 大小时，就表明，此时，Redis 实例的内存压力很大，很有可能会变慢。

解决方案

增加机器内存；

Redis의 메모리 요구 사항을 충족하기 위해 동일한 시스템에서 많은 양의 메모리가 필요한 프로세스를 실행하지 않으려면 별도의 시스템에서 Redis를 실행하세요.

클러스터 클러스터 수를 늘려 데이터 양을 공유하고 필요한 메모리를 줄이세요. 각 인스턴스.

AOF 및 디스크 I/O로 인한 지연

Redis는 데이터 안정성을 보장하기 위해 AOF 및 RDB 스냅샷을 사용하여 빠른 복구 및 지속성을 달성합니다.

appendfsync 구성을 사용하면 세 가지 다른 방법으로 디스크에서 쓰기 또는 fsync를 수행하도록 AOF를 구성할 수 있습니다. 이 설정은 CONFIG SET 명령을 사용하여 런타임에 수정할 수 있습니다(예: redis-cli CONFIG SET appendfsync no).

• no: Redis는 fsync를 수행하지 않습니다. 유일한 지연은 쓰기 호출에서 발생합니다. 쓰기는 반환하기 전에 커널 버퍼에 로그 레코드를 쓰기만 하면 됩니다.

• everysec: Redis는 초당 한 번씩 fsync를 실행합니다. fsync 작업을 비동기적으로 완료하려면 백그라운드 하위 스레드를 사용하세요. 최대 1초의 데이터가 손실됩니다.

• 항상: fsync는 모든 쓰기 작업에서 수행되고 클라이언트는 OK 코드로 응답됩니다(사실 Redis는 동시에 실행되는 많은 명령을 단일 fsync로 집계하려고 시도합니다). 데이터가 손실되지 않습니다. 이 모드에서는 일반적으로 성능이 매우 느리므로 짧은 시간에 fsync를 수행할 수 있는 빠른 디스크와 파일 시스템 구현을 사용하는 것이 좋습니다.

캐싱에는 일반적으로 Redis를 사용합니다. 데이터 손실은 완전히 악의적이며 높은 데이터 안정성이 필요하지 않습니다. no 또는 Everysec로 설정하는 것이 좋습니다.

또한 AOF 파일이 너무 커지는 것을 방지하기 위해 Redis는 AOF를 다시 작성하고 축소된 AOF 파일을 생성합니다.

구성 항목 no-appendfsync-on-rewrite를 yes로 설정할 수 있습니다. 이는 AOF가 다시 작성될 때 fsync 작업이 수행되지 않음을 의미합니다.

즉, Redis 인스턴스는 쓰기 명령을 메모리에 쓴 후 fsync 작업을 수행하기 위해 백그라운드 스레드를 호출하지 않고 직접 반환됩니다.

만료된 데이터 제거

Redis에는 만료된 데이터를 제거하는 두 가지 방법이 있습니다.

• 지연 삭제: 요청을 받으면 키가 삭제되기 전에 만료된 것으로 확인됩니다.

• 예약됨; 삭제: 일부 만료된 키를 삭제하기 위해 100밀리초마다.

예약 삭제 알고리즘은 다음과 같습니다.

키의 ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 개수를 무작위로 샘플링하고 만료된 키를 모두 삭제합니다.

키의 25% 이상이 만료된 것으로 확인되면 1단계를 수행합니다.

ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP는 기본적으로 20으로 설정되어 있으며 초당 10번 실행됩니다. 200개의 키를 삭제해도 큰 문제는 아닙니다.

두 번째 항목이 트리거되면 Redis는 만료된 데이터를 지속적으로 삭제하여 메모리를 해제하게 됩니다. 그리고 삭제가 차단됩니다.

발동 조건은 무엇인가요?

즉, 동일한 시간 매개변수로 많은 수의 키가 설정됩니다. 동시에 많은 수의 키가 만료되므로 키를 25% 미만으로 줄이려면 여러 번 삭제해야 합니다.

요약: 동시에 만료되는 키가 많으면 성능 변동이 발생할 수 있습니다.

해결책

키 배치가 동시에 만료되는 경우 EXPIREAT 및 EXPIRE의 만료 시간 매개변수에 특정 크기 범위 내의 임의의 숫자를 추가하여 키가 만료되도록 할 수 있습니다. 가까운 시간 범위 내에서 삭제되며 동시에 만료로 인한 압력을 피합니다.

bigkey

일반적으로 큰 데이터나 많은 수의 구성원 또는 목록을 포함하는 키를 큰 키라고 부릅니다. 아래에서는 몇 가지 실제 예를 사용하여 큰 키의 특성을 설명합니다.

• A STRING 키 유형, 값이 5MB(데이터가 너무 큼)

• LIST 유형 키, 목록 개수가 10000개(목록 개수가 너무 큼)

• ZSET 유형 키, 목록 개수 멤버는 10,000명입니다(멤버가 너무 많습니다)

• HASH 형식의 키입니다. 멤버 수는 1,000명에 불과하지만 이 멤버의 총 값 크기는 10MB입니다(멤버 크기가 너무 큼)

bigkey가 다음 문제:

• Redis 메모리가 계속 증가하여 OOM이 발생하거나 최대 메모리 설정 값에 도달하여 쓰기 차단 또는 중요한 키가 제거됨

• Redis Cluster의 특정 노드의 메모리는 다른 노드의 메모리보다 훨씬 높지만 Redis Cluster의 데이터 마이그레이션 최소 단위가 Key이기 때문에 노드의 메모리 균형을 맞출 수 없습니다.

• bigkey의 읽기 요청이 차지합니다. 대역폭이 너무 많아 속도가 느려지면 서버의 다른 서비스에도 영향을 미칩니다.

• 큰 키를 삭제하면 메인 라이브러리가 오랫동안 차단되고 동기화가 중단되거나 마스터-슬레이브 전환이 발생합니다.

Find bigkey

redis-rdb-tools 도구를 사용하여 맞춤형 방식으로 큰 키를 찾으세요.

솔루션

큰 키 분할예를 들어 Redis에서 수만 명의 구성원이 포함된 HASH 키를 여러 HASH 키로 분할하고 각 키의 구성원 수가 합리적인 범위 내에 있는지 확인합니다. 클러스터 구조에서는 큰 키의 분할이 노드 간의 메모리 균형에 중요한 역할을 할 수 있습니다.

대형 키의 비동기 정리

Redis는 4.0부터 UNLINK 명령을 제공했습니다. 이 명령은 들어오는 키를 비차단 방식으로 천천히 그리고 점진적으로 정리할 수 있습니다. UNLINK를 통해 대형 키 또는 초대형 키도 안전하게 삭제할 수 있습니다.

요약

다음 체크리스트는 Redis의 성능 저하가 발생할 때 문제를 효율적으로 해결하는 데 도움이 됩니다.

Redis의 현재 기본 성능을 확인하세요.

느린 명령으로 인해 발생한 문제를 찾으려면 느린 명령을 사용하세요.

느린 명령을 찾아 스캔을 사용하세요. 슬레이브 너무 큰 RDB 파일 로드로 인해 복사가 차단되었습니다.

메모리 대용량 페이지를 비활성화하고 메모리 대용량 페이지를 사용합니다. RDB 생성 중에 클라이언트가 수정한 데이터가 50B에 불과하더라도 Redis는 2MB의 데이터를 복사해야 합니다. 거대한 페이지. 많은 수의 명령어를 작성하면 많은 수의 복사본이 발생하여 성능이 저하됩니다.

Redis에서 사용하는 메모리가 너무 커서 스왑이 발생하는지 여부

AOF 구성이 합리적인지 여부에 관계없이 no-appendfsync-on-rewrite 구성 항목을 yes로 설정하여 AOF 재작성과 fsync가 디스크 IO 리소스를 두고 경쟁하는 것을 방지할 수 있습니다. , 결과적으로 Redis 대기 시간이 증가합니다.

bigkey는 일련의 문제를 가져올 것입니다. bigkey가 나타나지 않도록 분할하고 UNLINK를 통해 비동기적으로 삭제해야 합니다.

추천 학습:

Redis 학습 튜토리얼

위 내용은 Redis가 갑자기 느려지나요? Redis에 성능 문제가 있는지 판단하는 방법과 해결 방법을 분석해 보겠습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!