요청한대로 메모리를 제한 할 수없는 실제 이유는 MongoDB가 직접 사용하는 메모리를 관리하지 않기 때문에 OS가이를 수행 할 수 있기 때문입니다. MongoDB는 메모리에 모든 데이터를 매핑 한 다음 필요에 따라 OS 페이지에 메모리 안팎을 표시합니다. 결과적으로 MongoDB가이를 완전히 다른 방식으로 구현하거나 OS가 허용 할 때까지 (2.4 일 이후 Linux에서는 불가능) 사용 가능한 양을 직접 관리 할 수 없습니다.
현재 리소스를 실제로 분리하는 유일한 방법은 가상화 솔루션을 사용하고 MongoDB를 자체 VM에서 격리하는 것입니다. 예, 오버 헤드가 수반되지만 (하이퍼 바이저가 훨씬 더 나아졌지 만) 현재로서는 해당 수준의 리소스 제어에 대해 지불해야 할 가격입니다.
데이터 세트 및 인덱스가 사용 가능한 메모리를 초과하는 한 호스트에 다른 프로세스가 없어도 OOM Killer와 관련하여 MongoDB는 OOM Killer 문제를 일으킬 수 있습니다. 메모리 부족이 발생하지 않고 (기존 메모리를 원치 않는 것) 새로운 데이터와 인덱스를 계속 추가 / 터치하면 결국 사용 가능한 모든 RAM을 소비하게됩니다. 따라서 MongoDB를 실행할 때 항상 일부 스왑을 구성하는 것이 좋습니다.
https://docs.mongodb.com/manual/administration/production-notes/#swap
물론 LRU 데이터가 먼저 페이징되고 다른 프로세스가 결과를 차지할 수도 있지만 데이터 세트를 메모리에로드 한 다음 정적 상태를 유지하지 않으면 개념이 계속 적용됩니다. 걱정되는 경우 가장 좋은 방법은 MMS로 가져와 시간이 지남에 따라 사용량을 추적하는 것입니다.
http://mms.mongodb.com
업데이트 : 2015 년 8 월
이 답변을 썼기 때문에 상황이 다소 바뀌었고 정보가 약간 오래된 것입니다. 예를 들어, Linux에는 이제 cgroup 및 관련 기술 ( 예 : Docker 컨테이너 )이있어 프로덕션 환경의 모든 프로세스에서 사용하는 리소스 ( 메모리 포함 ) 를 더 잘 격리하고 제한 할 수있는 수준까지 발전했습니다. MongoDB와 같은 메모리 매핑.
또한 MongoDB 3.0+의 WiredTiger와 같은 MMAP 이외의 새로운 스토리지 엔진이 등장하면서 내장 기능을 사용 하여 MongoDB 의 캐시 크기 를 제한 할 수 있습니다 . 따라서 RAM 요구 사항은 이제 MongoDB 구성 방법, 실행 환경 및 선택한 스토리지 엔진에 따라 달라집니다.