Esse pode ser um processo longo e complicado, mas deixe-me primeiro dizer isso como um ponto de partida. Eu (e muitos outros com quem já trabalhei) consegui chegar mais perto do uso máximo de memória residente. Exatamente o que esse máximo é, vai variar de sistema para sistema e tem um monte de variáveis que entram em jogo, mas eu geralmente tiro para 60-80%, qualquer coisa maior é um bônus.
A próxima coisa a fazer é alguma leitura. Tem havido bastante escrito sobre este tópico, muitas vezes a partir da outra perspectiva (melhor eficiência de memória, ajustando-se mais à RAM quando ela está cheia, etc.). Por exemplo:
- Colocando mais dados na RAM Q & A (especificamente minha própria resposta sobre readahead )
- Mais informações em Configurações de leitura prévia
- Pergunta anterior semelhante sobre Uso de memória virtual do MongoDB
- Também há algumas Perguntas frequentes páginas nos documentos do MongoDB que são relevantes
Com tudo isso fora do caminho, você espera ter uma idéia decente sobre como ajustar seu sistema para tirar o máximo proveito da memória disponível (geralmente, mas nem sempre, derrubando a leitura e certificando-se de NUMA está desativada com sucesso), e são capazes de ver onde mais a pressão da memória pode estar chegando de. A próxima parte a ser entendida é um pouco mais complicada e envolve o funcionamento do diário do MongoDB, e como isso, por sua vez, interage com o modo como o kernel rastreia o uso da memória de processos individuais.
Isso é abordado em detalhes como parte de uma longa edição do MongoDB Jira - SERVIDOR-9415 . O que descobrimos ao investigar esse problema é que o comportamento do periódico ao fazer uma mescla de leituras e gravações poderia (drasticamente reduzir a memória residente relatada para o processo do MongoDB) (nem sempre, mas era reproduzível). A mecânica disso foi descrita em detalhes por Kristina Chodorow aqui e há mais detalhes na edição de Jira também.
Então, o que tudo isso significa?
Isso significa que o relatório e a interpretação das estatísticas de memória residentes são complexas, particularmente em um sistema que também faz gravações, especialmente se esse sistema tiver pressão de memória fora do processo mongod . Em geral, recomendo a seguinte metodologia:
- Leia em ( toque ou o pré-aquecimento manual com uma consulta / explicação grande) uma quantidade grande e conhecida de dados que devem caber na memória
- Execute algumas consultas, agregações etc. nesse conjunto de dados e verifique se a falha na página é mínima
- Se as falhas de página forem baixas, os dados estarão na memória, você terá um problema de geração de relatórios. Você pode repetir os testes com conjuntos de dados maiores até encontrar seu limite real.
- Se as falhas de página forem altas, os dados foram removidos, não foram totalmente carregados etc. e você deve investigar (pressão de leitura, pressão da memória, certificar-se de que o NUMA está desativado, etc.)
Eu geralmente recomendo executar o Monitoramento de MMS (gratuito) durante o teste, permitindo que você rastreie as estatísticas de memória, bem como as não Memória mapeada ao longo do tempo, falhas de página e muito mais, bem como mongostat (para sub um resolução mínima) para obter uma imagem decente do que está acontecendo.