Amazon RDS의 메모리가 부족합니다. 내가 걱정해야 할까?

Question

아마존 RDS 인스턴스가 있습니다. 메모리는 15GB에서 약 250MB까지 1-2 주에 걸쳐 설치가 중단되었습니다. 마지막 날에이 수치가 낮아짐에 따라 프리 메모리 (Freeable Memory)가이 범위 (250-350MB)로 떨어지는 톱니 패턴과 유사 해지기 시작했고 톱니 패턴으로 500 ~ 600MB까지 다시 올라갑니다.

애플리케이션 품질이 현저히 떨어지지 않았습니다. 그러나 DB에 메모리 부족과 충돌이 발생할 것으로 걱정됩니다.

RDS 인스턴스의 메모리가 부족해질 위험이 있습니까? 인스턴스가 올바르게 설정되었는지 확인하기 위해 살펴 봐야 할 설정이나 매개 변수가 있습니까? 이 톱니 모양의 원인은 무엇입니까?

Answer 1

Freeable 메모리 필드`의 자신의 프로세스에 대한 버퍼링 및 캐싱을 위해 MySQL이 사용됩니다. 사용 가능한 메모리 양은 시간이 지남에 따라 감소하는 것이 정상입니다. 더 많은 공간이 필요하기 때문에 오래된 정보가 나오는 것을 걱정하지 않을 것입니다.

Answer 2

짧은 대답 - FreeableMemory가 정말로 낮아지지 않으면 (약 100-200 Mb) 또는 중요한 스왑이 발생하지 않는 한 걱정할 필요가 없습니다 (RDS SwapUsage 미터법 참조).

FreeableMemory는 MySQL 메트릭이 아니지만 OS 메트릭입니다. 정확한 정의를 내리기는 어렵지만, OS를 요청한 사람에게 할당 할 수있는 메모리로 취급 할 수 있습니다 (귀하의 경우에는 MySQL이 될 가능성이 큽니다). MySQL에는 전체 메모리 사용을 일부 제한으로 제한하는 설정 집합이 있습니다 (실제로는 this과 같은 것을 사용할 수 있습니다). 일반적으로 최대 연결 수에 도달하지 못하기 때문에 인스턴스가이 한도에 도달 할 가능성은 거의 없지만 여전히 가능합니다.

이제 FreeableMemory 측정 항목의 '거부'로 돌아갑니다. MySQL의 경우 대부분의 메모리는 InnoDB 버퍼 풀 (자세한 내용은 here 참조)에 의해 소비됩니다. RDS 인스턴스는 기본적으로이 버퍼의 크기가 호스트 실제 메모리의 75 %로 설정되어 있습니다.이 경우 대략 12GB입니다. 이 버퍼는 읽기 및 쓰기 작업에서 사용 된 모든 DB 데이터를 캐싱하는 데 사용됩니다. 그래서이 경우 버퍼가 실제로 커지기 때문에 천천히 캐시 된 데이터로 채워집니다 (이 버퍼는 실제로 모든 DB를 캐시 할만큼 충분히 크다). 그래서 처음 인스턴스를 시작할 때이 버퍼는 비어 있습니다. 그리고 일단이 데이터가 캐시로 가져 오는 DB에 읽기/쓰기 작업을 시작하기보다. 그들은이 캐시가 가득 차서 새로운 요청이 왔을 때까지 여기에 머무를 것입니다. 이 시점에서 가장 최근에 사용한 데이터는 새로운 데이터로 대체됩니다. 따라서 DB 인스턴스를 다시 시작한 후 FreeableMemory가 처음으로 감소한 것은이 사실을 설명합니다. 나쁜 일이 아닙니다. DB를 빠르게 작동시키기 위해 가능한 한 많은 데이터를 캐시에 저장하려고합니다. 불쾌해질 수있는 유일한 것은이 버퍼의 일부 또는 전부가 물리적 메모리에서 스왑으로 푸시 될 때뿐입니다. 이 시점에서 엄청난 성능 저하가 발생합니다.

스왑 핑 가능성을 줄이기 위해 FreeableMemory 메트릭이 지속적으로 100-200Mb의 레벨에있는 경우 다른 용도로 사용되는 MySQL max 메모리를 조정하는 것이 좋습니다.

Answer 3

저는 같은 문제에 직면 해있었습니다. 인스턴스의 자유 메모리가 40MB 미만으로 떨어졌으며 인스턴스를 재부팅하면 메모리가 재설정되었습니다.