Redis 성능 문제 요약, 문제 해결 및 튜닝

머리말

Redis 성능 문제 해결 도구와 문제 현상에 대한 분석 및 처리를 소개합니다.

1. 일반적인 도구 및 수단

Redis에서 제공하는 명령어

1. 정보 명령

返回关于 Redis 服务器的各种信息和统计数值。
--主要包含以下信息：
server : 一般 Redis 服务器信息；
clients : 已连接客户端信息；
memory : 内存信息；
stats : 一般统计信息；
replication : 主/从复制信息
cpu : CPU 计算量统计信息
commandstats : Redis 命令统计信息
cluster : Redis 集群信息
keyspace : 数据库相关的统计信息

자세한 내용은 redis 연결 정보 얻기와 같은 info 메시지 명령을 사용하십시오.

Redis 메모리 정보:

자세한 내용은 중국어 문서 https://www.redis.net.cn/order/3676.html을 참조하십시오.

2. 모니터 명령

实时打印出 Redis 服务器接收到的命令，我们一般用这个命令来查询当前Redis正在执行哪些命令，可以短暂开启，不会阻塞Redis，压测验证多少对性能有点性能 大概20%；
比如说Redis进程CPU高了，那我们可以利用这个命令来查询Redis正在执行哪些命令

반환 값을 분석해 보겠습니다.
   0 127.0.0.1:3337] "세트" "우펑" "1111" 1635769192.420104 [0 127.0.0.1:3337 ] "
   얻기
   "
   "우펑"

   예를 들어, 첫 번째 줄의 1635769163.753976은 타임스탬프이고 단위는 s;
[0 127.0.0.1:3337], 즉 Redis 라이브러리 0에서 실행되는 명령에 대해 127.0.0.1:3337에 연결된 set 명령은 Redis 서비스에
   성능 문제가 있을 때 몇 초 동안 모니터 명령을 실행한 다음 s당 이러한 동시 명령을 계산할 수 있습니다. 문제를 판단하기 위해 명령이 실행됩니다.

3. 슬로우로그 명령

Redis Showlog 慢查询日志，
查询执行时间指的是不包括像客户端响应(talking)、发送回复等 IO 操作，而单单是执行	一个查询命令所耗费的时间。

현재 시점에서 최신 10개 명령 가져오기: slowlog get 3

명령 결과 분석:

시점과 타임스탬프가 있고 이를 모니터링 및 분석에 사용할 수 있으며, 어떤 시점에서 어떤 명령을 실행하는 데 걸리는 시간;

슬로우 쿼리 로그 큐 설정:
   슬로우 쿼리 임계값 즉, 슬로우 쿼리 로그에 기록되는 시간을 초과하여 쿼리 실행 시간을 몇 마이크로초(마이크로초, 1초 = 1,000,000마이크로초)로 기록해야 하는지 결정합니다.
     Get time
          CONFIG GET slowlog-log-slower-than

          즉, 기본 슬로우 쿼리 임계값은 10000마이크로초 즉, 10ms
     설정 시간:
          CONFIG set slowlog-log-slower-than 5000

여기서는 5000마이크로초, 즉 5ms로 설정 값이 너무 작지 않아야 하며(대기열이 자주 교체되어 기록 값 확인이 쉽지 않음) 너무 크지 않아야 합니다( 문제를 무시하기 쉽습니다)

느린 쿼리 로그 FIFO 대기열 설정:
항목 수 가져오기
CONFIG GET slowlog-max-len, 기본값은 128,
저장된 항목 수 설정
CONFIG SET slowlog-max-len 1000, 1000으로 변경

4. 빅키 명령

--bigkeys,用来查找大对象value的命令；

큰 열쇠는 무엇입니까?
    문자열형: 그것의 큰 것은 하나의 값이 매우 크다는 사실에 반영되며, 일반적으로 bigkey는 10KB를 초과한다고 간주됩니다.정식 환경에서 10M String형 개체가 있다고 분석했습니다.아직 문제가 없지만 고객 수가 증가함에 따라 항상 숨겨진 위험이 있으며 통신이 나중에 최적화됩니다
    .

–bigkeys를 사용하여 bigkey 검색:
    redis-cli -h ip -p port -a XXX --bigkeys 명령을 실행합니다.

다음은 현재 클러스터 환경의 노드 중 하나에서 가져온 것입니다.

bigkey가 가져오는 숨겨진 위험:
    1. Redis의 단일 스레드 특성으로 인해 일반적으로 bigkey를 작동하는 데 시간이 많이 걸립니다. 즉, Redis를 차단할 가능성이 더 크고 일반적으로 느린 쿼리에서 나타나는 클라이언트 차단 또는 장애 조치가 발생합니다.
    2. Bigkey는 매번 생성되는 네트워크 트래픽이 크다는 의미도 있는데, bigkey를 1MB로 가정하고 초당 클라이언트 방문 수를 1000으로 가정하면 초당 1000MB의 트래픽이 발생하는데 이는 일반 기가비트 네트워크 카드(바이트로 환산하면 128MB/s)를 사용하는 서버가 감당할 수 없는 수준이며, 이 서버에 다른 서비스 인스턴스가 있으면 끌어내려 zyfree-lazy-expire yes) 전략을 해결해야 합니다. 4. 클러스터의 경우 메모리 할당이 고르지 않고 대부분의 큰 키가 하나의 노드에 집중되어 메모리를 채울 수
    있습니다
    .

이러한 종류의 bigkey 솔루션에 대해: 1.
    E10 새로운 캐시는 데이터를 압축하고 저장하는 압축 기능 전략을 제공하거나 비즈니스를 위한 자체 압축 처리 2. 동시성이
    높은
    bigkey 의 경우     로컬 캐시를 채택합니다.

5. 벤치마크 명령

--benchmark命令，一般是用来作基准测试的，比如新上一台服务器，测试下简单的get set命令是否可以达到官方给的10多w的qps；

자세한 내용은 다음 문서를 참조하십시오.
    Redis 성능 테스트 - redis-benchmark 튜토리얼 https://blog.csdn.net/yangcs2009/article/details/50781530
    

6. 대기 시간 명령

latency测试运行中Redis的延迟，实现原理是不断的发送ping命令计算平均耗时；

    예를 들어, 아래 그림은 로컬 127.0.0.1 테스트를 보여줍니다. 테스트 중에 오른쪽 창에서 모니터 명령을 실행하여 실행 중인 명령을 쿼리합니다. 모두 ping 명령이며 테스트 결과에서 이 머신에서 가장 좋은 Redis 지연은 일반적으로 19us 정도입니다. 이것은 Redis 성능을 테스트하는 수단이기도 합니다. 모니터링 지연을 활성화합니다: CONFIG SET latency-monitor-threshold 100 #Unit 밀리초, 응답이 100밀리초를 초과함을 나타냅니다. s가 모니터링되며 기본값은 0이며 꺼짐 상태를 나타

냅니다
.

대기 시간 최신 명령

127.0.0.1:6379> latency latest
1) 1) "command" #事件名称
   2) (integer) 1405067976 #延迟发生的时间戳
   3) (integer) 251 #延迟 毫秒
   4) (integer) 1001 #事件的最大延迟

대기 시간 기록 명령

127.0.0.1:6379> latency history command #查看commend事件的历史延迟 返回160个元素
1) 1) (integer) 1405067822 #时间戳
   2) (integer) 251 #延迟
2) 1) (integer) 1405067941
   2) (integer) 1001

개인적으로 나는 그것을 닫는 것이 더 낫다고 생각하며, 이 명령의 유용성을 느끼지 못합니다. slowlog보다 낫습니다.

다른 수단

1. Redis 메모리 덤프 분석

주로 일부 기존 오픈 소스 도구에 의존합니다. 권장 링크는 다음과 같습니다.

1. RDR 도구를 사용하여 Redis https://blog.csdn.net/huantai3334/article/details/113464340에서 키가 차지하는 메모리 보기
2. rdbtools 도구를 사용하여 redis rdb 파일 https://www.cnblogs.com/cheyunhua/p/10598181.html을 구문 분석합니다.

2. 높은 CPU 문제

1. 대규모 동시성에서 높은 CPU,
   높은 동시성을 결정하는 방법:
   redis의 초당 쿼리 수 확인, –info stat

192.168.0.190:6382> info stats
# Stats
total_connections_received:3578768   ##所有连接数 累积
total_commands_processed:29111456557 ##服务器执行的命令数 累积
instantaneous_ops_per_sec:18570 ## 每秒执行的命令数
total_net_input_bytes:8788037875385  ## 网络流量-流入
total_net_output_bytes:162162655775051 ##网络流量-流出
instantaneous_input_kbps:5034.16 ##网络流量-流入-KB/sec
instantaneous_output_kbps:16361.97  ## 网络流量-流出-KB/sec
rejected_connections:0
sync_full:1
sync_partial_ok:0
sync_partial_ok:0
sync_partial_err:1
expired_keys:427378621
expired_stale_perc:1.11
expired_time_cap_reached_count:8
evicted_keys:1050467
keyspace_hits:11020187003   ## 命中的 Key数量   
keyspace_misses:1112525439  ## 未命中的 Key数量
pubsub_channels:5
pubsub_patterns:2
latest_fork_usec:845
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0
192.168.0.190:6382>

	查看当前都是在执行什么命令；--monitor
	查看当前是否存在慢查询；	--- slowlog get

위의 명령을 사용하여 예를 들어 어떤 비즈니스가 무한 루프에서 redis를 동시에 쿼리하는지 확인하고 일부 느린 쿼리로
인해
발생
합니다
.

3. 연결 수

Redis 연결 수가 많은 문제의 경우 먼저 info clients 명령을 사용하여 Redis 연결 수를 모니터링하는 방법에 대해 이야기하겠습니다.

192.168.0.190:6381> info clients
# Clients
connected_clients:2311   ###保持连接数
client_longest_output_list:0 ### 最大的输出缓冲区
client_biggest_input_buf:0 ### 最大的输入缓冲区
blocked_clients:0 ###阻塞的连接数
192.168.0.190:6381>

比如上述连接数2311是公司测试环境集群某一节点的连接数，看起来是挺大的，那如何判断是否正常，我们可以利用命令 clients list，来输出连接的详细信息，比如IP，执行的是什么命令等；
比如下面的命令结果，基本都是在执行ping，auth命令，是因为公司几十个服务都在连接一个Redis集群，客户端有开启连接检测功能，还有就是集群之间的通讯等维持着一定的连接数，所以整体是正常的；

如何判断有异常，主要是看这些连接是否是空闲很长的，即上面截图的idle=，空闲异常长极大说明连接泄漏了；
临时的解决方案：
修改redis.conf 里面的 time out 参数，使redis服务器主动断开连接；
然后看这个cmd= 一般是什么命令，结合redis操作的相关代码，进行排查；

또한 여기에 또 다른 성능 포인트가 있습니다. 즉, 입력 버퍼 및 출력 버퍼의 문제입니다. 사례의 후속 조치는 모니터 명령이 메모리 문제를 일으키는 것으로 나타났습니다. Redis5.0은 INFO 명령 클라이언트 모듈의 캐시 통계를 최적화합니다
https://www.cnblogs.com/chou1214/p/14470057.html

4. 메모리 문제

1. 메모리 부족, 스왑
   redis 읽기 및 쓰기에 대한 빈번한 교체는 느리고 디스크 io 읽기 및 쓰기는 메모리 읽기 및 쓰기보다 훨씬
   느
        립니다
        .

192.168.0.190:6381> info memory
# Memory
used_memory:166958840  ## 是Redis使用的内存总量，它包含了实际缓存占用的内存和Redis自身运行所占用的内存(如元数据、lua)。它是由Redis使用内存分配器分配的内存，所以这个数据并没有把内存碎片浪费掉的内存给统计进去
used_memory_human:159.22M ##redis现在占用的内存，有可能包括SWAP虚拟内存。
used_memory_rss:196255744 ##从操作系统上显示已经分配的内存总量。或者系统已分配的内存
used_memory_rss_human:187.16M ## 好看点的方式展示内存使用M为单位
used_memory_peak:247161800  ##redis的内存消耗峰值(以字节为单位)
used_memory_peak_human:235.71M
used_memory_peak_perc:67.55% ##used_memory_peak_perc：使用内存达到峰值内存的百分比，即(used_memory/ used_memory_peak) *100%
used_memory_overhead:55086750
used_memory_startup:6802568
used_memory_dataset:111872090
used_memory_dataset_perc:69.85%
total_system_memory:33566666752
total_system_memory_human:31.26G
used_memory_lua:83968
used_memory_lua_human:82.00K
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction  ##淘汰策略
mem_fragmentation_ratio:1.18 ##内存的碎片率，used_memory_rss/used_memory --4.0版本之后可以使用memory purge手动回收内存
mem_allocator:jemalloc-4.0.3
active_defrag_running:0 ##表示没有活动的defrag任务正在运行，1表示有活动的defrag任务正在运行（defrag:表示内存碎片整理）
lazyfree_pending_objects:0 ##表示redis执行lazy free操作,在等待被实际回收内容的键个数
192.168.0.190:6381>

          해결 방법:
               1. 메모리를 적절하게 늘리고 최대 메모리를 제한하고 적절한 메모리 교체 전략을 조정합니다.
               2. rdb 파일을 분석하여 항상 메모리를 점유하는 키와 정상 여부를 확인합니다.

2. 메모리 부족, 메모리 부족 캐시 키의 빈번한 교체는
   느린 애플리케이션, 낮은 캐시 적중률 및 Redis의 빈번한 쓰기로 이어집니다 메모리
   에서 키가 교체되었는지 판단하는 방법:
   info stats 명령 결과에서 evicted_keys 값으로 판단할 수 있으며 maxmemory 제한으로 인해 재활용 및 삭제된 키의 수를 나타냅니다
   .

   해결책:

   1. 메모리를 적절하게 늘리고, 최대 메모리를 제한하고, 적절한 메모리 교체 전략을 조정하십시오.
   2. rdb 파일을 분석하여 어떤 키가 항상 메모리를 점유하고 있는지, 정상인지 확인합니다.

3.      메모리 단편화 문제 및 해결책
        개인적으로 튜닝이 어렵다고 생각하지만 캐싱에 적합하지 않은 자주 업데이트되는 bigkeys를 처리하는 것이 가능합니다.
   

메모리 단편화 속도를 완화할 수 있는 솔루션(Redis4 이후):
     Redis는 자동 메모리 단편화 청소 메커니즘을 위한 매개변수 설정을 제공합니다. 파편 청소가 Redis 요청 처리 성능에 미치는 영향을 줄이기 위해 파편 청소의 시작 및 종료 시간과 CPU 점유 비율을 제어하는 ​​매개변수를 설정할 수 있습니다.
     먼저 자동 메모리 조각 모음 활성화:
          config set activedefrag yes
     그런 다음 메모리 정리 트리거 조건 설정:
          active-defrag-ignore-bytes 100mb: 메모리 조각화 바이트 수가 100MB에 도달하면 정리 시작, active-
          defrag-threshold-lower 10: 메모리 조각화 공간이 운영 체제에서 Redis에 할당된 총 공간의 10%를 차지하면 정리가 시작됩니다.
     마지막으로 정리 작업이 차지하는 CPU 시간 비율의 상한 및 하한을 제어합니다.
          active-defrag-cycle-min 25: 자동 정리 프로세스가 사용하는 CPU 시간 비율이 25% 이상임을 나타내며 정리가 정상적으로 수행될 수 있음을 나타냅니다. active-defrag-cycle-max 75: 자동 정리 프로세스가 사용하는 CPU 시간 비율이 75% 이하임을 나타냅니다
          .

5. 지속성 문제

Redis 지속성의 두 가지 방법:

1. RDB
2. AOF

    자세한 내용은 블로그 RDB 및 AOF 프로세스 https://www.cnblogs.com/iamsach/p/8490387.html을 참조하십시오.

     이 두 종류의 지속성의 관점에서 볼 때 공통된 성능 지점이 있습니다. 즉, Fork 하위 프로세스, RDBFork 하위 프로세스, AOF가 Fork 하위 프로세스를 다시 작성하는 프로세스입니다
     .
     포크를 실행하는 동안 메인 프로세스는 자신의 메모리 페이지 테이블을 자식 프로세스에 복사해야 하는데 인스턴스가 크면 복사 프로세스에 많은 시간이 소요됩니다.
     동시에 이 포크 프로세스는 많은 CPU 리소스를 소비하게 되며 포크가 완료되기 전에 전체 Redis 인스턴스가 차단되어 클라이언트 요청을 처리할 수 없습니다. 이 시점에서 CPU 리소스가 이미 부족한 경우 포크가 더 오래 걸리고 심지어 두 번째 수준에 도달하여 Redis의 성능에 심각한 영향을 미칩니다.

fork 하위 프로세스의 영향을 확인하는 방법:
     INFO 명령을 실행하면 내부의 Stats 필드에 마지막 포크에 소요된 시간을 마이크로초 단위로 나타내는 latest_fork_usec가 있습니다
     . 이 작업에 시간이 오래 걸린다면 경계해야 합니다. 즉, 이 기간 동안 전체 Redis 인스턴스는 사용할 수 없는 상태입니다.

     다른 하나는 RDB가 Redis 메모리 스냅샷을 디스크에 기록한다는 것입니다. 이 프로세스는 디스크 IO에 대해 매우 특별합니다. 이 프로세스는 Redis 프로세스를 차단하지 않지만 서버에 다른 인스턴스나 서비스가 있는 경우 영향을 받습니다.

RDB 작업은 어디에 있습니까:
     데이터 지속성을 위해 RDB를 생성하는 것 외에도 마스터-슬레이브 노드가 처음으로 데이터 동기화를 설정할 때 마스터 노드는 하위 프로세스를 생성하여 RDB를 생성한 다음 전체 동기화를 위해 슬레이브 노드로 보냅니다.따라서 이 프로세스는 Redis의 성능에도 영향을 미칩니다
     .

해결책:
     1. Redis 인스턴스의 메모리 제어: 10G 미만으로 유지하십시오. fork 실행에 걸리는 시간은 인스턴스 크기와 관련이 있습니다. 인스턴스가 클수록 더 오래 걸립니다. 시간 소비는 시스템과도 관련이 있습니다. 가상 머신은 물리적 머신보다 더 오래 걸립니다. 4. 마스터-슬레이브 데이터베이스의 전체 동기화 가능성을 줄입니다. repl-backlog-size 매개변수를 적절하게 증가시켜 마스터-슬레이브의 전체 동기화를      방지
      합니다      .

6. 사례와 분석의 현장 시연, 개선 예정

사례 1: RDB로 인한 높은 Linux IO 로드, https://blog.csdn.net/wf_feng/article/details/121182522,
사례 2: Redis Timeout wait for idle object 문제 해결, https://blog.csdn.net/wf_feng/article/details/121046703?spm=1001.201 4.3001.5501
사례 3:

7. Redis 속도 저하에 대한 체크리스트 요약

• 현재 환경에서 Redis 인스턴스의 기준 성능을 가져와 느린지 여부를 확인합니다.
• 느린 쿼리 명령을 사용했습니까? 그렇다면 다른 명령을 사용하여 느린 쿼리 명령을 바꾸거나 집계 계산 명령을 클라이언트에 넣으십시오.
• 시간이 많이 걸리는 포크 하위 프로세스
• 동시성이 매우 높습니까? 초당 쿼리 수입니다.
• 네트워크 트래픽이 최고조에 달했는지 여부
• 메모리가 꽉 찼고 스왑 교체가 발생했습니다.
• 빅키가 존재합니까?
• Redis AOF 구성 수준은 무엇입니까? 비즈니스 수준에 이러한 수준의 안정성이 정말로 필요합니까? 고성능이 필요하고 동시에 데이터 손실을 허용하는 경우 no-appendfsync-on-rewrite 구성 항목을 yes로 설정하여 디스크 IO 리소스에 대한 AOF 재작성 및 fsync 경쟁을 방지하여 결과적으로 Redis 대기 시간이 증가할 수 있습니다. 물론 고성능과 높은 신뢰성이 모두 필요하다면 AOF 로그를 기록하기 위한 디스크로 고속 솔리드 스테이트 디스크를 사용하는 것이 가장 좋습니다.
• Redis 인스턴스의 실행 환경에서 투명한 huge page 메커니즘이 활성화되어 있습니까? 그렇다면 메모리 거대한 페이지 메커니즘을 직접 끄십시오.
• Redis 마스터-슬레이브 클러스터가 실행 중입니까? 그렇다면 마스터-슬레이브 복제 시 대용량 RDB 파일을 로드하여 슬레이브 데이터베이스가 차단되지 않도록 마스터 데이터베이스 인스턴스의 데이터 크기를 2~4GB로 제어하십시오.