- 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 '^(Swap|Size)'
로그인 후 복사
출력 결과는 다음과 같습니다
Size: 1256 kB
Swap: 0 kB
Size: 4 kB
Swap: 0 kB
Size: 132 kB
Swap: 0 kB
Size: 63488 kB
Swap: 0 kB
Size: 132 kB
Swap: 0 kB
Size: 65404 kB
Swap: 0 kB
Size: 1921024 kB
Swap: 0 kB
...
로그인 후 복사
이 결과는 Redis 프로세스의 메모리 사용량을 나열합니다. E SIZE의 각 줄은 Redis가 사용하는 메모리 조각을 나타내며, SIZE 아래의 Swap은 이 크기의 크기가 디스크에서 교체되었음을 나타냅니다. 이 두 값이 같다면 이 메모리의 데이터가 동일하다는 의미입니다. 데이터가 모두 디스크로 완전히 교체되었습니다.
예를 들어 디스크에 아주 적은 양의 데이터만 스왑하는 경우 각 스왑이 해당 크기에서 작은 비율을 차지하므로 영향은 크지 않습니다. 수백 메가바이트 또는 심지어 GB의 메모리가 디스크로 교체되면 경계해야 합니다. 이 경우 Redis의 성능은 확실히 급격히 떨어집니다.
해결책
Redis가 사용할 수 있는 충분한 메모리가 있도록 머신의 메모리를 늘립니다.
- 메모리 공간을 정리하고 Redis가 사용할 수 있도록 충분한 메모리를 해제한 다음 Redis가 메모리를 재사용할 수 있도록 Swap of Redis를 해제합니다.
-
Redis의 Swap을 해제하는 과정에서는 일반적으로 인스턴스를 다시 시작해야 합니다. 인스턴스 재시작이 비즈니스에 미치는 영향을 피하기 위해 일반적으로 마스터-슬레이브 전환이 먼저 수행된 다음 이전 마스터 노드의 Swap이 수행됩니다. 해제되고 이전 마스터 노드 인스턴스가 다시 시작됩니다. 슬레이브 데이터베이스 데이터 동기화가 완료된 후 마스터-슬레이브 전환을 수행합니다.
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 작업이 발생하고 영향을 미칩니다. 레디스의 성능. * Redis가 느리게 응답하게 됩니다.
3) 다른 프로그램은 리소스를 두고 경쟁합니다 마지막으로 알려드릴 점은 Redis 머신은 전용이며 Redis 인스턴스를 배포하는 데만 사용된다는 점입니다. 상대적으로 조용한 환경을 제공하지 마십시오. for Redis” 환경에서는 다른 프로그램이 CPU, 메모리, 디스크 리소스를 점유하여 Redis에 할당된 리소스가 부족해지는 것을 방지합니다.
추천 학습:
Redis 비디오 튜토리얼
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
