ElastiCache Redis에서 스왑 방지

ElastiCache Redis 인스턴스 스와핑에 계속 문제가 있습니다. Amazon은 스왑 사용량 급증을 감지하고 ElastiCache 인스턴스를 다시 시작하여 캐시 된 모든 항목을 잃어 버리는 일부 내부 모니터링 기능을 갖추고있는 것으로 보입니다. 지난 14 일 동안 ElastiCache 인스턴스에서 BytesUsedForCache (파란색 선) 및 SwapUsage (오렌지색 선) 차트는 다음과 같습니다.

스왑 사용량 증가 패턴이 ElastiCache 인스턴스의 재부팅을 트리거하는 것처럼 보이며 모든 캐시 된 항목이 손실됩니다 (BytesUsedForCache가 0으로 떨어짐).

ElastiCache 대시 보드의 '캐시 이벤트'탭에는 해당 항목이 있습니다.

소스 ID | 타입 | 날짜 | 행사

캐시 인스턴스 ID | 캐시 클러스터 | 9 월 22 일 화요일 07:34:47 GMT-400 2015 | 캐시 노드 0001이 다시 시작되었습니다.

캐시 인스턴스 ID | 캐시 클러스터 | 9 월 22 일 화요일 07:34:42 GMT-400 2015 | 노드 0001에서 캐시 엔진을 다시 시작하는 중 오류가 발생했습니다.

캐시 인스턴스 ID | 캐시 클러스터 | 일 9 월 20 일 11:13:05 GMT-400 2015 | 캐시 노드 0001이 다시 시작되었습니다.

캐시 인스턴스 ID | 캐시 클러스터 | 목 9 월 17 일 22:59:50 GMT-400 2015 | 캐시 노드 0001이 다시 시작되었습니다.

캐시 인스턴스 ID | 캐시 클러스터 | 수 9 월 16 일 10:36:52 GMT-400 2015 | 캐시 노드 0001이 다시 시작되었습니다.

캐시 인스턴스 ID | 캐시 클러스터 | 9 월 15 일 화요일 05:02:35 GMT-400 2015 | 캐시 노드 0001이 다시 시작되었습니다.

(이전 항목 스니핑)

아마존 주장 :

SwapUsage- 정상적인 사용에서 Memcached 또는 Redis는 스왑을 수행하지 않아야합니다.

관련 (기본이 아닌) 설정 :

• 인스턴스 유형 : cache.r3.2xlarge
• maxmemory-policy: allkeys-lru (우리는 이전에 큰 차이없이 기본 volatile-lru를 사용 했었습니다)
• maxmemory-samples: 10
• reserved-memory: 2500000000
• 인스턴스에서 INFO 명령을 확인하면 mem_fragmentation_ratio1.00에서 1.05 사이입니다.

AWS 지원팀에 연락하여 유용한 조언을 얻지 못했습니다. 예약 메모리를 훨씬 더 높이는 것이 좋습니다 (기본값은 0이고 예약 된 용량은 2.5GB 임). 이 캐시 인스턴스에 대해 복제 또는 스냅 샷을 설정하지 않았으므로 BGSAVE가 발생하지 않아 추가 메모리 사용이 발생하지 않을 것이라고 생각합니다.

maxmemorycache.r3.2xlarge의 캡은 62,495,129,600 바이트이며, 우리는 우리의 뚜껑을 명중 (마이너스 우리하더라도 reserved-memory) 빠르게, 그것은하지 않는 한, 이렇게 빨리 호스트 운영 체제가 여기에 너무 많은 스왑을 사용하여 압력을 느낄 것이라고 나에게 이상한 것, 그리고 아마존은 어떤 이유로 OS 스왑 피스 설정을 높였습니다. 왜 우리가 ElastiCache / Redis에서 스왑 사용량을 많이 발생 시켰는지, 또는 해결 방법이 있습니까?

아무도 여기에 대답을하지 않았으므로 내가 우리에게 도움이 된 유일한 것을 공유 할 것이라고 생각했습니다. 첫째, 이러한 아이디어는 효과가 없었 습니다.

• 더 큰 캐시 인스턴스 유형 : 캐시보다 작은 인스턴스에서 동일한 문제가 발생했습니다 .r3.2xlarge
• tweaking maxmemory-policy: volatile-lru와 allkeys-lru는 아무런 차이를 보이지 않는 것 같습니다.
• 부딪 히다 maxmemory-samples
• 부딪 히다 reserved-memory
• 모든 클라이언트가 최대 7 일까지 허용하는 드문 발신자가 거의 있지만 대부분의 발신자는 1-6 시간의 만료 시간을 사용하여 일반적으로 최대 24 시간의 만료 시간을 설정합니다.

마지막으로 도움이 된 것은 다음과 같습니다. 12 시간마다 작업을 실행하면 10,000 개 단위의 청크로 모든 키에 대해 스캔 을 실행합니다 COUNT. 다음은 동일한 인스턴스의 BytesUsedForCache입니다. 이전과 동일한 설정으로 이전보다 훨씬 더 많이 사용되는 cache.r3.2xlarge 인스턴스입니다.

메모리 사용량의 톱니 하락은 크론 작업 시간에 해당합니다. 이 2 주 동안 스왑 사용량이 ~ 45MB로 줄었습니다 (다시 시작하기 전에 ~ 5GB로 줄었습니다). ElastiCache의 캐시 이벤트 탭은 더 이상 캐시 재시작 이벤트를보고하지 않습니다.

그렇습니다. 사용자가 스스로 할 필요는없고, Redis는이 정리를 스스로 처리 할만큼 똑똑해야합니다. 왜 이것이 작동합니까? 글쎄, Redis는 만료 된 키를 많이 또는 선제 적으로 청소하지 않고 대신 GET 중에 만료 된 키를 제거 합니다. 또는 Redis가 메모리가 가득 찼음을 인식하면 새로운 각 SET의 키를 제거하기 시작하지만 그 시점에서 Redis에 이미 호스가 있다는 이론이 있습니다.

나는 이것이 오래되었다는 것을 알고 있지만 AWS 설명서에서 이것에 부딪쳤다.

https://aws.amazon.com/elasticache/pricing/ r3.2xlarge의 메모리는 58.2GB라고합니다.

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html 시스템 최대 메모리가 62GB (maxmemory-policy가 시작될 때)이고 변경할 수 없음을 나타냅니다. . AWS의 Redis와 상관없이 우리는 교환 할 것 같습니다.