Groupcache: 메모리 제한의 상한 문제

안녕,

그룹 캐시 덕분에 거의 성공적으로 사용하고 있습니다.

내가 더 이해하고 싶은 한 가지는 응용 프로그램 메모리 요구의 상한을 추정/알고 있는 방법입니다. 기본 기능은 단순히 그룹 캐시에서 서비스를 제공하는 것입니다.

그래서 우리는 6GB vm의 실행 중인 그룹 캐시를 가지고 있고, 우리의 첫 번째 의도는 사용 가능한 캐시 크기를 5GB로 설정하고 1GB를 운영 체제와 사물을 위한 여유 공간으로 남겨두는 것이었습니다.

OOM 킬러가 호출되어 프로덕션 부하에서 즉시 충돌했습니다. 그래서 우리는 OOM 킬러가 시작되기 전에 프로세스가 사용하는 메모리가 6GB 미만으로 유지되도록 이 숫자를 2GB 미만으로 낮추었습니다.

그래서 다음 단계는 메모리를 프로파일링하는 것이었고 힙 크기는 그룹 캐시에서 구성한 2GB를 훨씬 초과하지 않습니다. 그러나 프로세스는 4-6GB의 램을 사용하게 됩니다.

그래서 가장 최근의 시도는 몇 분마다 수동으로 debug.FreeOSMemory()를 호출하는 것이었고, 이것이 실행되면 얼마 지나지 않아 프로세스에 필요한 메모리 양이 줄어들고 OS에 많은 것이 반환됩니다.

그러나 OOM 킬러로 인해 가끔 충돌이 발생합니다. 이 경우를 버퍼링하기 위해 SSD 스왑을 추가했지만 문제가 없는지 48시간이 지난 후 이러한 시스템에 대한 트래픽이 일시적으로 증가하여(상당히 증가) 단일 시스템에서 OOM이 종료된 다음 이러한 일이 발생한 다른 여러 시스템으로 눈덩이처럼 불어났습니다.

따라서 이 작업을 수행하기 위해 2GB 캐시 설정(groupcache.NewGroup의 두 번째 매개변수라고도 함)을 더 낮은 입술 1GB로 삭제할 수 있지만 캐시에 1GB만 사용할 수 있는 6GB VM을 갖는 것은 약간 어리석은 것처럼 보입니다.

이것은 캐싱을 위한 메모리 관리에 대한 go의 접근 방식을 사용하는 것의 단점일 뿐입니다.

중요한지 확실하지 않지만 우리의 사용 사례는 dl.google.com과 매우 유사합니다. 우리는 중간 크기의 파일(50mb-1gb, 100MB 청크에 캐시됨)의 다운로드를 제공하고 있으며 그룹 캐시는 우리가 제공해야 하는 파일이 있는 더 느리고 더 비싼 API 앞에 사용됩니다. 그래서 자연스럽게 이것을 찾을 때 문제에 대한 훌륭한 해결책처럼 보입니다.

이러한 유형의 문제를 관리하기 위해 공유할 수 있는 모든 팁에 대해 대단히 감사합니다. 제가 놓치고 있는 부분이 있다는 생각이 계속 듭니다.

공유할 수 있는 통찰력을 제공해 주셔서 감사합니다.

• 스콧