Redis 최적화 경험 요약-PHP 튜토리얼-php.cn

메모리 관리 최적화와 관련하여 이 문서에서는 모든 사람에게 도움이 되기를 바라며 Redis 최적화 경험 요약을 주로 공유합니다.

Redis Hash는 값 내부의 HashMap입니다. Map의 멤버 수가 상대적으로 적다면 1차원 선형과 유사한 컴팩트 형식을 사용하여 Map을 저장하므로 포인터의 메모리 오버헤드가 많이 절약됩니다. 이 매개변수 제어는 redis.conf 구성 파일의 다음 2개 항목에 해당합니다.

hash-max-zipmap-entries 64 hash-max-zipmap-value 512

값 맵에 멤버가 몇 개 이하인 경우 , 기본값은 64입니다. 즉, 값이 64개 미만인 경우 선형 압축 저장소가 사용됩니다. 값이 이 값을 초과하면 자동으로 실수로 변환됩니다. 해시맵.

hash-max-zipmap-value는 값 맵의 각 멤버 값 길이가 특정 바이트 수를 초과하지 않는 경우 선형 컴팩트 저장소를 사용하여 공간을 절약한다는 의미입니다.

위 두 가지 조건 중 하나라도 설정된 값을 초과하면 실제 HashMap으로 변환되어 더 이상 메모리를 절약하지 않습니다. 그렇다면 값이 클수록 더 좋은 것은 당연합니다. HashMap은 검색 및 연산의 시간 복잡도가 O(1)인 반면, Hash를 버리고 1차원 저장소를 채택하면 O(n)의 시간 복잡도가 발생하므로 구성원 수가 적으면 영향이 크지 않습니다. 성능이 심각하므로 이 값의 설정을 고려해야 합니다. 일반적으로 시간 비용과 공간 비용 간의 가장 근본적인 균형입니다. XList-Max-Ziplist-Value 64 list-max-ziplist-entries 512

list 데이터 유형 데이터 유형 노드 값이 바이트 수보다 작습니다.

메모리 사전 할당:

Redis의 내부 구현은 Memcache에 비해 메모리 할당을 많이 최적화하지 않았습니다. 메모리 조각화는 어느 정도 존재하지만 대부분의 경우 이는 Redis의 성능 병목 현상이 되지 않습니다. 그러나 Redis에 저장된 데이터의 대부분이 숫자인 경우 Redis는 메모리 할당 비용을 절약하기 위해 내부적으로 공유 정수 방식을 사용합니다. 즉, 시스템이 시작되면 먼저 1부터 n까지의 숫자 개체를 할당합니다. 풀에서 저장된 데이터가 이 값 범위 내에 있으면 개체를 풀에서 직접 가져와 참조 계산을 통해 공유합니다. 이렇게 하면 시스템이 많은 수의 데이터를 저장하는 경우에도 일정 시간을 절약할 수 있습니다. 이 매개변수 값 n을 설정하려면 소스 코드에서 REDIS_SHARED_INTEGERS 줄을 수정해야 합니다. 기본값은 10000입니다. 수정 후 다시 컴파일하면 됩니다.

지속성 메커니즘:

시간이 지정된 스냅샷 방법(스냅샷):

이 지속성 방법은 실제로 Redis 내부의 타이머 이벤트입니다. 매 고정된 시간마다 현재 데이터의 변경 횟수와 시간이 구성된 지속성을 충족하는지 확인합니다. 트리거 조건이 충족되면 운영 체제 분기 호출을 통해 하위 프로세스가 생성됩니다. 이 하위 프로세스는 기본적으로 상위 프로세스와 동일한 주소 공간을 공유합니다. 이때 전체 메모리는 하위 프로세스를 통해 이동할 수 있습니다. 쓰기가 있는 경우 운영 체제는 상위 프로세스와 하위 프로세스가 서로 영향을 미치지 않도록 메모리 페이지 단위로 쓰기 중 복사를 수행합니다.

이 지속성의 주요 단점은 예약된 스냅샷이 일정 기간 내의 메모리 이미지만 나타내므로 시스템을 다시 시작하면 마지막 스냅샷과 다시 시작 사이의 모든 데이터가 손실된다는 것입니다.

명령문 기반 추가 방법(aof):

aof 방법은 실제로 mysql의 명령문 기반 binlog 방법과 유사합니다. 즉, Redis 메모리 데이터를 변경하는 모든 명령이 로그 파일에 추가됩니다. 즉, 다음과 같습니다. 로그 파일 Redis의 영구 데이터입니다.

aof 방식의 가장 큰 단점은 로그 파일을 추가하면 크기가 너무 커질 수 있다는 점입니다. 데이터를 복원하기 위해 시스템을 다시 시작할 때 aof 방식을 사용하면 데이터 로딩 속도가 매우 느려질 수 있습니다. 물론 수십 기가바이트의 데이터를 로드하는 데 몇 시간이 걸리는 것은 디스크 파일 읽기 속도가 느리기 때문이 아니라, 읽는 모든 명령을 메모리에서 실행해야 하기 때문이다. 또한 각 명령마다 로그를 작성해야 하므로 aof를 사용하면 Redis의 읽기 및 쓰기 성능도 저하됩니다.

다른 Redis 인스턴스에 데이터를 저장하는 것을 고려할 수 있습니다. 각 인스턴스의 메모리 크기는 약 2G입니다. 이렇게 하면 캐시 오류가 시스템에 미치는 영향을 줄일 수 있을 뿐만 아니라 데이터 복구 속도도 높일 수 있습니다. .속도가 빠르지만 시스템 설계가 어느 정도 복잡해집니다.

Redis 지속성 충돌 문제:

Redis 온라인 운영 및 유지 관리 경험이 있는 사람들은 Redis가 물리적 메모리를 많이 사용하지만 실제 총 물리적 메모리 용량을 초과하지 않으면 불안정해지거나 심지어 충돌할 수도 있다는 것을 알게 될 것입니다. 스냅샷 지속성을 기반으로 한 포크 시스템 호출로 인해 메모리 사용량이 두 배로 늘어난다고 생각됩니다. 더티 페이지는 복사되지만 일반적으로 시스템이 짧은 시간 내에 모든 페이지를 쓰지 않아 복사가 발생하는 이유는 무엇입니까?

Redis 지속성은 버퍼 IO를 사용한다는 것입니다. 소위 버퍼 IO는 Redis가 영구 파일에 대한 쓰기 및 읽기 작업에 물리적 메모리의 페이지 캐시를 사용하는 반면 대부분의 데이터베이스 시스템은 이를 우회하기 위해 Direct IO를 사용한다는 것입니다. Redis 영구 파일(특히 스냅샷 파일)이 너무 커서 이를 읽고 쓰면 디스크 파일의 데이터가 운영 체제에서와 같이 물리적 메모리에 로드됩니다. 이 파일에 대한 캐시 계층과 이 캐시 계층의 데이터 및 Redis 메모리에서 관리되는 데이터는 실제로 반복적으로 저장되지만 물리적 메모리가 부족할 때 커널은 페이지 캐시를 제거하지만 커널은 생각할 가능성이 높습니다. 특정 페이지 캐시 차단이 더 중요하며 프로세스가 스왑을 시작하도록 허용하면 시스템이 불안정해지거나 충돌이 발생할 수 있습니다. 우리의 경험에 따르면 Redis 물리적 메모리 사용량이 총 메모리 용량의 3/5를 초과하면 더 위험해집니다.

요약:

1. 비즈니스 요구 사항에 따라 적절한 데이터 유형을 선택하고 다양한 애플리케이션 시나리오에 해당하는 컴팩트 스토리지 매개변수를 설정하세요.

2. 비즈니스 시나리오에 데이터 지속성이 필요하지 않은 경우 모든 지속성 방법을 끄면 최상의 성능과 최대 메모리 사용량을 얻을 수 있습니다.

3. 지속성을 사용해야 하는 경우 다시 시작하는 동안 일부 데이터 손실을 허용할 수 있는지 여부에 따라 스냅샷 모드와 명령문 추가 모드 중에서 선택하세요.

4. Redis 머신의 물리적 메모리 사용량이 전체 실제 메모리의 3/5를 초과하지 않도록 하세요.

redis.conf의 maxmemory 옵션은 Redis에게 물리적 메모리가 얼마나 사용되었는지 이후에 후속 쓰기 요청을 거부하기 시작하도록 지시합니다. 이 매개변수는 Redis가 너무 많은 물리적 메모리를 사용하여 스왑을 유발하여 궁극적으로 성능에 심각한 영향을 미치지 않도록 보호할 수 있습니다. 심지어 충돌합니다.

redis.conf 파일의 vm 활성화는 no