A verdadeira razão pela qual você não pode fazer o que pede (limitar a memória) é porque o MongoDB não gerencia a memória que usa diretamente - ele permite que o SO faça isso. O MongoDB apenas mapeia todos os seus dados de memória e, em seguida, faz com que a página do SO entre e saia da memória conforme necessário. Como resultado, não há gerenciamento direto da quantidade usada possível até que o MongoDB implemente isso de uma maneira completamente diferente, ou o sistema operacional permita (não é possível no Linux desde os 2,4 dias).

A única maneira de realmente segregar recursos no momento é usar uma solução de virtualização e isolar o MongoDB em sua própria VM. Sim, há despesas gerais envolvidas (embora os hipervisores tenham melhorado muito), mas no momento esse é o preço a ser pago por esse nível de controle de recursos.

Em termos do OOM Killer, mesmo sem outros processos no host, desde que seu conjunto de dados e índices excedam a memória disponível, o MongoDB pode atingir problemas do OOM Killer. Isso ocorre por causa de como os dados são paginados para fora da memória - se não houver pressão de memória (nada mais deseja memória residente) e você continuar adicionando/tocando novos dados e índices, eventualmente ele crescerá para consumir toda a RAM disponível. Daí a recomendação de sempre configurar algum swap ao executar o MongoDB:

https://docs.mongodb.com/manual/administration/production-notes/#swap

É claro que os dados LRU serão paginados primeiro, outros processos também podem ocupar o res mem, mas o conceito ainda se aplica, a menos que você carregue seu conjunto de dados na memória e ele permaneça estático. A melhor coisa a fazer se você estiver preocupado é colocá-lo no MMS e acompanhar o uso ao longo do tempo:

http://mms.mongodb.com

Atualização: agosto de 2015

Desde que escrevi esta resposta, as coisas mudaram um pouco e as informações estão um pouco desatualizadas. Por exemplo, o Linux agora tem cgroups e tecnologias relacionadas ( contêineres Docker, por exemplo) que amadureceram a ponto de permitir que você isole e limite melhor os recursos ( incluindo memória ) consumidos por qualquer processo em um ambiente de produção, mesmo aquele que usa mapeamento de memória como MongoDB.

Além disso, com o advento de novos mecanismos de armazenamento além do MMAP, como o WiredTiger no MongoDB 3.0+, você pode usar a funcionalidade integrada para limitar o tamanho do cache do MongoDB. Portanto, os requisitos de RAM agora realmente dependem de como você escolhe configurar o MongoDB, em qual ambiente você o executa e qual mecanismo de armazenamento você escolhe.

O MongoDB usará a memória livre disponível para armazenamento em cache e fará a troca para o disco conforme necessário para fornecer memória para outros aplicativos no mesmo servidor. Para obter o melhor desempenho, você precisará de RAM suficiente para manter seus índices e dados usados ​​com frequência ("conjunto de trabalho") na memória.

Leitura útil:

• FAQ do MongoDB: O MongoDB requer muita RAM
• Wiki do MongoDB: Verificando o uso da memória do servidor

Algumas coisas mudaram em anos sobre o MongoDB.

TL;DR

Se o mecanismo de armazenamento MMAPv1 for usado no MongoDB, o working settamanho deve caber na RAM . https://docs.mongodb.com/manual/faq/diagnostics/#must-my-working-set-size-fit-ram

Se o mecanismo de armazenamento WiredTiger for usado no MongoDB, não será necessário se preocupar com a RAM ser adequada working setou não . https://docs.mongodb.com/manual/faq/diagnostics/#memory-diagnostics-for-the-wiredtiger-storage-engine

Diagnóstico de memória para o mecanismo de armazenamento WiredTiger

O tamanho do meu conjunto de trabalho deve caber na RAM?

Não.

Como calculo a quantidade de RAM necessária para o meu aplicativo?

Com o WiredTiger, o MongoDB utiliza o cache interno do WiredTiger e o cache do sistema de arquivos.

Alterado na versão 3.2: A partir do MongoDB 3.2, o cache interno do WiredTiger, por padrão, usará o maior de:

60% de RAM menos 1 GB ou 1 GB.