Redis가 느린 이유와 문제 해결 방법에 대한 간략한 설명-Redis-php.cn

이 기사에서는 Redis에 대한 관련 지식을 제공합니다. Redis가 느린 이유와 문제 해결 방법을 주로 소개합니다. 이는 모든 사람의 학습이나 업무에 중요한 의미가 있습니다. 학습 가치에 대해 살펴보겠습니다. 모든 사람에게 도움이 되기를 바랍니다.

Redis가 느린 이유와 문제 해결 방법에 대한 간략한 설명

권장 학습: Redis 동영상 튜토리얼

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

문제 해결 아이디어

Redis 인스턴스의 메모리 상한이 maxmemory인 경우 다음과 같은 문제가 발생할 수도 있습니다. 속도를 늦추려면 Redis를 사용하세요.

Redis를 순수 캐시로 사용할 때 일반적으로 이 인스턴스에 대한 메모리 제한 maxmemory를 설정한 다음 데이터 제거 전략을 설정합니다. 인스턴스의 메모리가 maxmemory에 도달하면 이후 새로운 데이터를 쓸 때마다 작업 지연이 증가하는 것을 확인할 수 있습니다.

속도 저하 원인

Redis 메모리가 maxmemory에 도달하면 새 데이터를 쓸 때마다 Redis는 먼저 인스턴스에서 데이터의 일부를 삭제하여 전체 인스턴스의 메모리를 maxmemory 미만으로 유지해야 합니다. 새로운 데이터를 쓸 수 있나요?

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

allkeys-lru: 키가 만료되도록 설정되었는지 여부에 관계없이 가장 최근에 액세스한 키가 만료됩니다. key
휘발성-lru: 최근 액세스 및 만료 시간이 가장 짧은 키만 제거되도록 설정됩니다. key
allkeys-ttl: 키가 만료되도록 설정되었는지 여부에 관계없이 곧 만료될 키입니다. Noeviction: 키가 제거되지 않습니다. 인스턴스 메모리가 maxmeory에 도달하면 새 데이터를 쓴 후 바로 오류가 반환됩니다.
allkeys-lfu: 키에 관계 없이 만료를 설정하고 키를 제거합니다. 가장 낮은 액세스 빈도(버전 4.0+에서 지원)
휘발성-lfu: 가장 낮은 액세스 빈도를 가진 키만 제거하고 만료 시간을 설정합니다(버전 4.0+에서 지원)
구체적으로 어떤 전략을 사용해야 합니까? 특정 비즈니스 시나리오에 따라 이를 수행합니다. 일반적으로 가장 일반적으로 사용되는 것은 allkeys-lru / 휘발성-lru 제거 전략입니다. 해당 처리 논리는 매번 인스턴스에서 키 배치를 무작위로 가져온 다음(이 숫자는 구성 가능) 가장 적게 액세스된 키를 제거하는 것입니다. 그런 다음 나머지 키를 사용하여 풀에 키를 임시 저장하고 계속해서 키 배치를 무작위로 선택하여 이전 풀의 키와 비교한 다음 가장 적게 액세스한 키를 제거합니다. 인스턴스 메모리가 maxmemory 아래로 떨어질 때까지 이 작업을 반복합니다.
Redis에서 데이터를 제거하는 논리는 만료된 키를 삭제하는 논리와 동일하며 명령이 실제로 실행되기 전에 실행됩니다. 즉, Redis 작업의 지연도 증가합니다. 게다가 쓰기 OPS가 높을수록 지연도 더욱 분명해집니다.

또한 이때 Redis 인스턴스에 bigkey도 저장되어 있는 경우 메모리 해제를 위해 bigkey를 제거하고 삭제하는 데에도 시간이 오래 걸립니다.

보셨나요? 빅키의 위험은 어디에나 있기 때문에 앞서 빅키를 최대한 많이 보관하지 말라고 상기시켜 드린 것입니다.

해결 방법

큰 키 저장을 피하고 메모리 해제 시간을 줄입니다.

제거 전략이 무작위 제거로 변경되어 LRU보다 훨씬 빠릅니다(비즈니스 상황에 따라 다름)

인스턴스를 분할하여 제거합니다. key 압력이 여러 인스턴스에 분산됩니다

Redis 4.0 이상을 사용하는 경우layz-free 메커니즘을 켜고 백그라운드 스레드에서 키 제거 및 메모리 해제 작업을 실행합니다(lazyfree-lazy-eviction = yes 구성) )
문제 해결 아이디어

우리 모두는 애플리케이션이 운영 체제에서 메모리를 적용할 때 메모리 페이지별로 적용되며 기존 메모리 페이지 크기는 4KB라는 것을 모두 알고 있습니다. .

2.6.38부터 Linux 커널은 메모리 거대 페이지 메커니즘을 지원합니다. 이를 통해 애플리케이션은 운영 체제에서 2MB 단위로 메모리를 신청할 수 있습니다.

애플리케이션이 매번 운영체제에 적용하는 메모리 단위가 커지지만, 이는 메모리를 적용하는 데 걸리는 시간도 길어진다는 의미이기도 합니다.

속도 저하 원인
- Redis는 백그라운드 RDB 및 AOF 재작성을 실행할 때 포크 하위 프로세스를 사용하여 이를 처리합니다. 그러나 메인 프로세스가 자식 프로세스를 분기한 후에도 이때 메인 프로세스는 여전히 쓰기 요청을 받을 수 있으며, 들어오는 쓰기 요청은 Copy On Write(쓰기 시 복사) 방식을 사용하여 메모리 데이터를 작동합니다.
- 즉, 기본 프로세스에 수정해야 할 데이터가 있으면 Redis는 기존 메모리의 데이터를 직접 수정하지 않고 먼저 메모리 데이터를 복사한 다음 새 메모리의 데이터를 수정합니다. "기록 중 복사"라고 불리는 것입니다.
- 글을 써야 하는 사람은 먼저 복사한 다음 수정해야 한다는 의미로 기록 중 복사를 이해할 수도 있습니다.
- 이것의 장점은 상위 프로세스의 모든 쓰기 작업이 하위 프로세스의 데이터 지속성에 영향을 미치지 않는다는 것입니다(하위 프로세스는 포크 순간 전체 인스턴스의 모든 데이터만 유지하고 새 데이터는 신경 쓰지 않습니다). 데이터 변경), 하위 프로세스에는 디스크에 유지되는 메모리 스냅샷만 필요하기 때문입니다.
- 그러나 메인 프로세스가 메모리 데이터를 복사할 때 이 단계에는 새로운 메모리 적용이 포함된다는 점에 유의하세요. 운영 체제가 이때 메모리 대형 페이지를 켜면 이 기간 동안 클라이언트가 10B만 수정하더라도 Redis가 메모리를 적용할 경우 운영 체제에도 2MB 단위로 적용되므로 메모리 적용에 소요되는 시간이 길어지고 이로 인해 각 쓰기 요청의 지연이 증가하여 Redis 성능에 영향을 미칩니다.
- 마찬가지로 이 쓰기 요청이 빅키에서 작동하는 경우 메인 프로세스가 빅키 메모리 블록을 복사할 때 한 번에 요청되는 메모리가 더 커지고 시간도 길어집니다. 여기서도 bigkey가 성능에 영향을 미치는 것을 볼 수 있습니다.
Solution

거대한 페이지 메커니즘을 끄세요.

먼저 Redis 머신에 대형 페이지가 활성화되어 있는지 확인해야 합니다.
```
$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never
```
로그인 후 복사
출력 옵션이 항상인 경우 이는 대형 페이지 메커니즘이 현재 활성화되어 있다는 의미이므로 이 기능을 꺼야 합니다.
```
$ echo never > /sys/kernel/mm/transparent_hugepage/enabled
```
로그인 후 복사
실제로 운영 체제가 제공하는 메모리 대용량 페이지 메커니즘의 장점은 특정 프로그램에서 메모리를 적용해야 하는 응용 프로그램의 수를 줄일 수 있다는 것입니다.
그러나 Redis와 같이 성능과 대기 시간에 매우 민감한 데이터베이스의 경우 Redis가 메모리를 적용할 때마다 가능한 한 짧은 시간이 걸리기를 바라므로 Redis 머신에서는 이 메커니즘을 활성화하지 않는 것이 좋습니다. .
원인 3: Swap 사용
문제 해결 아이디어
Redis가 갑자기 매우 느려지고 각 작업에 수백 밀리초 또는 심지어 몇 초가 걸리는 경우 Redis Swap이 사용되는지 확인해야 하며 이 경우 경우 Redis는 기본적으로 고성능 서비스를 제공할 수 없습니다.
속도 저하 원인
스왑이란 무엇인가요? Swap을 사용하면 Redis 성능이 저하되는 이유는 무엇입니까?
운영 체제에 대해 조금이라도 알고 계시다면, 메모리 부족이 애플리케이션에 미치는 영향을 완화하기 위해 운영 체제에서는 메모리 사용량을 버퍼링하기 위해 메모리에 있는 데이터의 일부를 디스크로 이동할 수 있도록 허용한다는 사실을 아실 것입니다. 이러한 메모리 데이터를 디스크로 Swap하는 영역이 Swap입니다.
문제는 메모리에 있는 데이터를 디스크로 이동할 때 Redis가 다시 데이터에 액세스할 때 디스크에 액세스하는 속도가 메모리에 액세스하는 속도보다 수백 배 느리다는 것입니다. 특히 성능 요구 사항이 매우 높고 성능에 매우 민감한 Redis와 같은 데이터베이스의 경우 이러한 작업 지연은 용납될 수 없습니다.
이때 Swap이 사용되는지 확인하기 위해 Redis 머신의 메모리 사용량을 확인해야 합니다. Redis 프로세스가 Swap을 사용하는지 여부는 다음과 같은 방법으로 확인할 수 있습니다.
```
# 先找到 Redis 的进程 ID
$ ps -aux | grep redis-server
 
# 查看 Redis Swap 使用情况
$ cat /proc/$pid/smaps | egrep &#39;^(Swap|Size)&#39;
```
로그인 후 복사
출력 결과는 다음과 같습니다

크기: 1256 kB
스왑: 0 kB
크기: 4 kB
스왑: 0k B
크기: 132 kB
스왑: 0 kB
크기: 63488 kB
스왑: 0 kB
크기: 132 kB
스왑: 0 kB
크기: 65404 kB
스왑:
...

이 결과에는 Redis 프로세스의 메모리 사용량이 나열됩니다.

Size의 각 행은 Redis에서 사용하는 메모리 크기를 나타냅니다. Size 아래의 Swap은 이 메모리의 크기와 디스크로 스왑된 데이터의 양을 나타냅니다. 이는 이 메모리의 데이터가 모두 디스크로 완전히 교체되었음을 의미합니다.

예를 들어 디스크에 아주 적은 양의 데이터만 스왑한다면 각 스왑이 해당 Size에서 작은 비율을 차지하므로 그 영향은 그다지 크지 않습니다. 수백 메가바이트 또는 심지어 GB의 메모리가 디스크로 교체되면 경계해야 합니다. 이 경우 Redis의 성능은 확실히 급격히 떨어집니다.

해결책
Redis가 사용할 수 있는 충분한 메모리를 확보할 수 있도록 머신의 메모리를 늘립니다.
- 메모리 공간을 정리하고 Redis가 사용할 만큼 충분한 메모리를 해제한 다음 Redis가 메모리를 재사용할 수 있도록 Redis 스왑을 해제합니다.
Redis가 Swap을 사용하게 되면 이때 Redis의 성능은 기본적으로 고성능 요구 사항을 충족할 수 없다는 것을 알 수 있으므로(무술이 폐지되는 것을 이해하실 수 있습니다), 이러한 상황도 미리 방지해야 합니다.

이를 방지하는 방법은 Redis 머신의 메모리 및 Swap 사용량을 모니터링하고 메모리가 부족하거나 Swap을 사용할 때 알람을 울리고 적시에 처리해야합니다.

원인 4: 네트워크 대역폭 과부하

문제 해결 아이디어
위의 성능 문제를 일으키는 시나리오를 피하고 Redis가 오랫동안 안정적으로 실행되었지만 특정 시점이 지나면 Redis 작업이 중단되는 경우 갑자기 느려지기 시작해서 계속 느려지는 이유는 무엇인가요?

이때 Redis 머신의 네트워크 대역폭이 과부하되었는지, 머신 전체의 네트워크 대역폭을 채우는 인스턴스가 있는지 확인해야 합니다.

속도 저하 이유
네트워크 대역폭이 과부하되면 서버는 TCP 계층과 네트워크 계층에서 패킷 전송 지연, 패킷 손실 등을 경험하게 됩니다.

Redis의 높은 성능은 운영 메모리 외에도 네트워크 IO에 있습니다. 네트워크 IO에 병목 현상이 발생하면 Redis의 성능에도 심각한 영향을 미치게 됩니다.

Solution
Redis 인스턴스의 네트워크 대역폭이 가득 찼는지 적시에 확인하십시오. 일반적인 비즈니스 액세스인 경우 과도한 작업으로 인해 이 머신의 다른 인스턴스에 영향을 미치지 않도록 적시에 인스턴스를 확장하거나 마이그레이션해야 합니다. 이 인스턴스의 트래픽입니다.
- 운영 및 유지 관리 수준에서는 네트워크 트래픽을 포함하여 Redis 시스템의 다양한 지표에 대한 모니터링을 강화해야 합니다. 네트워크 트래픽이 특정 임계값에 도달하면 사전 경보, 적시 확인 및 확장이 필요합니다.
- 이유 5: 기타 이유
1) 짧은 연결이 자주 발생하는 경우
비즈니스 애플리케이션에서는 짧은 연결이 자주 발생하는 것을 방지하기 위해 Redis를 작동하기 위해 긴 연결을 사용해야 합니다.

짧은 연결이 자주 발생하면 Redis가 연결을 설정하고 해제하는 데 많은 시간을 소비하게 되며 TCP의 3방향 핸드셰이크 및 4방향 웨이브도 액세스 지연을 증가시킵니다.

2) 운영 및 유지보수 모니터링
앞서 말씀드렸던 Redis의 둔화를 미리 예측하려면 모니터링을 잘하는 것이 필수라고 말씀드렸습니다.

모니터링은 실제로 Redis의 다양한 런타임 표시기 모음입니다. 일반적인 접근 방식은 모니터링 프로그램이 Redis의 INFO 정보를 정기적으로 수집한 다음 INFO 정보의 상태 데이터를 기반으로 데이터 표시 및 경보를 수행하는 것입니다.

여기서 꼭 기억해야 할 점은 모니터링 스크립트를 작성하거나 오픈 소스 모니터링 구성 요소를 사용할 때 이를 가볍게 여겨서는 안 된다는 것입니다.

Redis에 액세스하기 위해 모니터링 스크립트를 작성할 때 짧은 연결이 자주 발생하는 것을 피하기 위해 긴 연결을 사용하여 상태 정보를 수집해 보세요. 동시에 비즈니스 요청에 영향을 주지 않도록 Redis에 대한 액세스 빈도를 제어하는 데도 주의를 기울여야 합니다.

일부 오픈 소스 모니터링 구성 요소를 사용할 때는 이러한 구성 요소의 구현 원리를 이해하고 이러한 구성 요소를 올바르게 구성하여 모니터링 구성 요소의 버그를 방지하는 것이 가장 좋습니다. 이로 인해 짧은 시간에 많은 수의 Redis 작업이 발생하고 영향을 미칩니다. 레디스의 성능.

당시 DBA가 일부 오픈 소스 구성 요소를 사용할 때 구성 및 사용 문제로 인해 모니터링 프로그램이 자주 설정되고 Redis에서 연결이 끊어져 Redis가 느리게 응답하는 현상이 발생했습니다.

3) 다른 프로그램은 리소스를 두고 경쟁합니다

마지막으로 Redis 머신은 Redis 인스턴스를 배포하는 데만 사용되는 것이 가장 좋습니다. Redis에 상대적으로 조용한 환경을 제공하지 마십시오. .” 환경을 통해 다른 프로그램이 CPU, 메모리, 디스크 리소스를 점유하여 Redis에 할당된 리소스가 부족해지는 것을 방지합니다.

추천 학습: Redis 비디오 튜토리얼