Redis의 일반적인 대기 시간 문제를 해결하는 방법

복잡한 명령을 사용하세요

Redis를 사용할 때 액세스 지연이 갑자기 증가하는 경우 어떻게 문제를 해결하나요?

먼저 첫 번째 단계는 Redis의 느린 로그를 확인하는 것입니다. Redis의 느린 로그 명령 통계 기능을 통해 다음 옵션을 설정하여 어떤 명령이 실행에 큰 지연을 일으키는지 확인할 수 있습니다.

먼저 Redis의 느린 로그 임계값을 설정합니다. 임계값을 초과하는 명령만 기록됩니다. 여기서 단위는 마이크로초입니다. 예를 들어 느린 로그 임계값을 5밀리초로 설정하고 최근 1000개의 느린 로그 레코드만 유지하도록 설정합니다. :

# 命令执行超过5毫秒记录慢日志
CONFIG SET slowlog-log-slower-than 5000
# 只保留最近1000条慢日志
CONFIG SET slowlog-max-len 1000

설정이 완료된 후 지연이 5밀리초보다 크면 실행된 모든 명령이 Redis에 기록됩니다. SLOWLOG get 5를 실행하여 최신 5개의 느린 로그를 쿼리합니다.

127.0.0.1:6379> SLOWLOG get 5
1) 1) (integer) 32693       # 慢日志ID
   2) (integer) 1593763337  # 执行时间
   3) (integer) 5299        # 执行耗时(微妙)
   4) 1) "LRANGE"           # 具体执行的命令和参数
      2) "user_list_2000"
      3) "0"
      4) "-1"
2) 1) (integer) 32692
   2) (integer) 1593763337
   3) (integer) 5044
   4) 1) "GET"
      2) "book_price_1000"
...

느린 로그 기록을 보면, 어떤 명령이 언제 실행되었는지 알 수 있습니다. 명령은 정렬, sunion, zunionstore, 키, 스캔 또는 실행 시 작동되는 데이터의 양과 같이 O(N) 이상의 복잡한 명령을 자주 사용하는 경우입니다. O(N) 명령은 상대적으로 크기가 크므로 이러한 상황에서는 Redis에서 데이터를 처리할 때 시간이 매우 많이 걸립니다.

Redis 인스턴스의 CPU 사용량은 높지만 서비스 요청량이 크지 않은 경우에는 복잡성이 높은 명령을 사용했기 때문일 수 있습니다.

이러한 복잡한 명령을 사용하지 않고, 한 번에 너무 많은 데이터를 얻지 않는 것이 해결책입니다. Redis가 제때에 처리하고 반환할 수 있도록 매번 소량의 데이터를 조작해 보세요.

Storing bigkey

느린 로그를 쿼리하여 이것이 매우 복잡한 명령으로 인해 발생한 것이 아니라는 것을 알게 되면(예: SET 및 DELETE 작업이 느린 로그 레코드에 나타남) Redis가 bigkey를 작성했는지 의심해야 합니다. 상태.

Redis가 새로운 데이터를 쓸 때 메모리 공간이 할당되고, Redis에서 데이터가 삭제되면 해당 메모리 공간도 해제됩니다.

키에 기록된 데이터가 매우 큰 경우 Redis에서 메모리를 할당하는 데에도 시간이 더 많이 소요됩니다. 마찬가지로 이 키의 데이터를 삭제하면 메모리를 해제하는 데 오랜 시간이 걸립니다.

빅키가 작성되고 있는지 비즈니스 코드를 확인해야 합니다. 작성된 데이터의 양을 평가해야 합니다. 비즈니스 계층에서는 하나의 키에 너무 많은 데이터를 저장하지 않아야 합니다.

bigkey 문제에 대응하여 Redis는 버전 4.0에서 공식적으로 지연 없는 메커니즘을 출시했습니다. 이 메커니즘은 bigkey의 메모리를 비동기적으로 해제하고 Redis 성능에 미치는 영향을 줄이는 데 사용됩니다. 그럼에도 불구하고 Bigkey를 사용하는 것은 권장하지 않습니다. Bigkey는 클러스터 마이그레이션 프로세스 중에도 마이그레이션 성능에 영향을 미칩니다. 이에 대해서는 나중에 클러스터 관련 기사에서 자세히 소개하겠습니다.

집중 만료

Redis를 사용하면 큰 지연이 발생하지 않는 경우가 있지만 특정 시점에 갑자기 지연의 파도가 발생하고 느린 시점이 특정 시점과 같이 매우 규칙적으로 발생합니다. 정시에 또는 일정한 간격으로.

이런 경우, 일괄적으로 만료된 키가 많은지 여부를 고려해야 합니다.

특정 시점에 다수의 키가 만료되는 경우, 이 시점에 Redis에 접속할 때 지연 시간이 늘어날 수 있습니다.

Redis의 만료 전략은 일반 삭제 + 지연 삭제라는 두 가지 전략을 채택합니다.

Redis의 정기적 삭제 예약 작업도 Redis 메인 스레드에서 실행됩니다. 즉, 활성 만료를 실행하는 동안 오류가 발생합니다. 많은 수의 만료된 키를 삭제하려면 비즈니스 액세스 중에 비즈니스 요청을 처리하기 전에 만료된 작업이 완료될 때까지 기다려야 합니다. 이때 비즈니스 접근 지연이 늘어나는 문제가 발생하게 되며, 최대 지연 시간은 25밀리초이다.

그리고 이 액세스 지연은 느린 로그에 기록되지 않습니다. 느린 로그는 특정 명령의 실제 실행 시간만을 기록하며, 작업 명령이 느린 로그 임계값에 도달하기 전에 Redis 활성 만료 정책이 실행됩니다. 비즈니스 지연이 증가했습니다.

해결책은 중앙 집중식 만료에 임의의 시간을 추가하고 만료되어야 하는 키의 시간을 분산시키는 것입니다.

인스턴스 메모리가 상한에 도달했습니다

때때로 Redis를 순수 캐시로 사용할 때 인스턴스에 대해 메모리 상한 maxmemory를 설정한 다음 LRU 제거 전략을 활성화합니다.

인스턴스의 메모리가 maxmemory에 도달하면 매번 새 데이터를 쓰는 것이 느려질 수 있습니다.

속도가 느려지는 이유는 Redis 메모리가 maxmemory에 도달하면 각각의 새 데이터가 기록되기 전에 메모리를 maxmemory 미만으로 유지하기 위해 데이터의 일부를 삭제해야 하기 때문입니다.

오래된 데이터를 제거하는 이 논리에도 시간이 걸리며 구체적인 시간은 구성된 제거 전략에 따라 다릅니다.

포크는 시간이 많이 걸립니다

Redis에 자동 RDB 생성 및 AOF 다시 쓰기 기능이 켜져 있는 경우 RDB 및 AOF 재작성이 백그라운드에서 생성될 때 Redis의 액세스 지연이 증가할 수 있으며 이러한 작업이 완료되면 지연이 사라집니다.

이러한 상황이 발생하는 경우 일반적으로 RDB 및 AOF 재작성 작업을 실행하면서 발생합니다.

RDB 및 AOF를 생성하려면 상위 프로세스가 데이터 지속성을 위해 하위 프로세스를 분기해야 합니다. 전체 인스턴스가 많은 양을 차지하는 경우 상위 프로세스는 메모리 페이지 테이블을 하위 프로세스에 복사해야 합니다. 그러면 메모리를 복사해야 합니다. 이 프로세스는 많은 CPU 리소스를 소비합니다. 포크가 완료되기 전에 전체 인스턴스가 차단되고 요청을 처리할 수 없습니다. 현재 CPU 리소스가 부족하여 포크가 더 오래 걸리거나 심지어 몇 초에 도달할 수도 있습니다. 이는 Redis의 성능에 심각한 영향을 미칩니다.

Binding CPU

서비스를 배포할 때 프로그램이 여러 CPU를 사용할 때 성능을 향상하고 컨텍스트 전환으로 인한 성능 손실을 줄이기 위해 일반적으로 CPU를 바인딩하는 프로세스를 사용합니다.

그러나 Redis를 사용할 때는 다음과 같은 이유로 권장하지 않습니다.

CPU 바인딩 Redis에서는 데이터 지속성을 수행할 때 분기된 하위 프로세스가 상위 프로세스의 CPU 사용량 기본 설정을 상속하게 됩니다. 이때 하위 프로세스는 데이터 지속성을 위해 많은 양의 CPU 리소스를 소비하게 됩니다. 메인 프로세스와의 CPU 경합이 발생하여 메인 프로세스의 CPU 리소스가 부족해지고 액세스 지연이 증가하게 됩니다.

따라서 Redis 프로세스를 배포할 때 RDB 및 AOF 재작성 메커니즘을 활성화해야 하는 경우 CPU 바인딩 작업을 수행해서는 안 됩니다.

스왑 사용

Redis가 갑자기 매우 느려지는 경우 각 액세스에 최대 수백 시간이 소요됩니다. 밀리초 또는 초 단위로 Redis가 Swap을 사용하는지 확인합니다. 이 경우 Redis는 기본적으로 고성능 서비스를 제공할 수 없습니다.

우리는 운영 체제가 스왑 메커니즘을 제공한다는 것을 알고 있습니다. 그 목적은 메모리가 부족할 때 메모리 사용량을 버퍼링하기 위해 메모리의 데이터 일부를 디스크로 바꾸는 것입니다.

하지만 메모리의 데이터가 디스크로 교체된 후 데이터에 액세스하려면 디스크에서 읽어야 하는데, 이는 메모리보다 훨씬 느립니다!

특히 Redis와 같은 고성능 인 메모리 데이터베이스의 경우 Redis의 메모리가 디스크로 교체되는 경우 Redis와 같이 성능에 매우 민감한 데이터베이스에는 이 작업 시간이 허용되지 않습니다. 운영체제 Swap을 일시적으로 종료할 수 있습니다

네트워크 카드 부하가 너무 높습니다

특정 시점부터 속도가 느려지기 시작하여 계속되는 것이 특징입니다. 이때 기기의 네트워크 카드 트래픽이 소진되었는지 확인해야 합니다.

높은 네트워크 부하로 인해 네트워크 계층 및 TCP 수준에서 데이터 전송 지연 및 데이터 손실과 같은 문제가 발생할 수 있습니다. 메모리 외에도 Redis는 뛰어난 네트워크 IO 성능으로 인해 고성능입니다. 그러나 요청 수가 계속 증가함에 따라 네트워크 카드의 로드도 그에 따라 증가합니다.

이러한 경우에는 이 머신의 어떤 Redis 인스턴스가 트래픽이 과도하여 네트워크 대역폭을 채우고 있는지 확인한 후 갑작스러운 트래픽 증가가 정상적인 비즈니스 상황인지 확인해야 합니다. 또는 제때에 인스턴스를 마이그레이션하여 이 시스템의 다른 인스턴스가 영향을 받지 않도록 하세요.

위 내용은 Redis의 일반적인 대기 시간 문제를 해결하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!