O SO pergunta / resposta vinculado por quanta nos comentários está correto, o "Conjunto de trabalho" é basicamente a quantidade de dados E índices que estarão ativos / em uso pelo seu sistema.
Você não pode dizer a partir de db.stats()
o que será, a menos que você ache que precisará ter todo o conjunto de dados e todo o índice na RAM. Ou seja, você pode calcular o conjunto de trabalho máximo para esse banco de dados, mas não o conjunto de trabalho ativo real. O máximo é a soma de:
- dataSize - O tamanho total dos dados contidos neste banco de dados
- indexSize - O tamanho total de todos os índices criados neste banco de dados
No seu caso, esse máximo seria de aproximadamente 30,45 MiB, dada a saída que você colou.
Para rastrear o uso real da memória, eu recomendaria uma combinação dos números de db.stats()
e os gráficos de memória (memória residente em particular) disponíveis na ferramenta de monitoramento gratuita - MMS .
Atualização (04/08/2013):
A versão 2.4 adicionou um Estimador do tamanho do conjunto de trabalho ao comando serverStatus - é apenas uma estimativa, mas pode ser usado como um guia e como verifique se as outras figuras e estimativas acima fazem sentido para sua instância do MongoDB.
Atualização (setembro de 2016):
Três anos após a minha resposta original e as coisas são muito mais complicadas - geralmente, obter o tamanho de seus dados e seus índices ainda é um bom ponto de partida. Mas, descobrir as coisas no MongoDB agora dependerá de qual mecanismo de armazenamento você está usando. Além disso, a versão 3.0 removeu o estimador Working Set vinculado acima para o MMAP como parte do trabalho de bloqueio no nível de coleta (consulte SERVER-13783 ). Existe agora (por exemplo) as estatísticas de cache para o WiredTiger
motor como um substituto assumindo que você tenha feito o salto para o novo motor. Para MMAP
, a recomendação geral é analisar as falhas de página métrica como um proxy para saber se seus dados estão se encaixando na memória ou não.