Servidor de produção do Mongodb muito lento em comparação com o armazenamento temporário

Question

Temos dois conjuntos de servidores de banco de dados e de aplicativos em execução no RPSpace VPS. Produção e Encenação. O aplicativo está no Rails e o db é MongoDB.

Enquanto o staging (com tantos documentos quanto prod, 55k) funciona bem, servidor de produção é terrivelmente lento. Por um fator de 20 ou mais. Até mesmo consultas simples demoram quase 18 segundos!

Aqui está o que eu fiz até agora e ainda não consigo chegar ao fundo disso.

• Serviço Mongo reiniciado.
• Verificou os tempos de ping nos aplicativos e servidores de banco de dados para ver se a rede era o problema. Não é.
• Explicitamente executou create_indexes nos modelos, mas sem sucesso.
• A opção de perfil do mongo foi ativada, mas não me deu nenhuma informação extra além do que eu já tinha.

Aqui está o instantâneo mongostat da produção quando algumas chamadas de banco de dados estão sendo executadas:

insert  query update delete getmore command flushes mapped  vsize    res faults locked % idx miss %     qr|qw   ar|aw  netIn netOut  conn       time 
     0      0      0      0       0       1       0  1.95g  4.55g   122m     76        0          0       0|0     1|0    62b     1k     2   09:07:25 
     0      0      0      0       0       1       0  1.95g  4.55g   119m    121        0          0       0|0     1|0    62b     1k     2   09:07:26 
     0      0      0      0       0       1       0  1.95g  4.55g   120m     80        0          0       0|0     1|0    62b     1k     2   09:07:27 
     0      0      0      0       0       1       0  1.95g  4.55g   118m    116        0          0       0|0     1|0    62b     1k     2   09:07:28 

Por que existem tantas falhas? Isso é normal? Qualquer ajuda / insight seria muito apreciada.

    

Answer 1

Acontece que o culpado foi outra coisa juntos. Pacote de relatório de erros do Ubuntu chamado Whoopsie. Veja como foi rastreado.

• O Mongostat mostrou um número anormalmente alto de falhas, o que significava que os dados não estavam disponíveis na RAM e que o mongo provavelmente estava atingindo o disco em todas as consultas.
• Em seguida, emiti o comando free do Linux. Isso não ajudou. Na verdade, engana ao reportar RAM livre. Veja aqui www.linuxatemyram. com
• O comando top também não funcionou e sempre mostrou que o maior uso de memória foi pelo mongo, que não foi superior a 20%. Por que o mongo não estava usando a memória restante?!
• Uma rápida pesquisa no Google por ferramentas de monitoramento do sistema / memória mostrou htop como favorito.

Aqui está a saída htop no servidor. link - imagem

Uma RAM enorme de 43,7% comido por whoopsie !! Um grande momento. Acontece que isso afetou os servidores de produção e de preparação, mas a preparação ainda sobreviveu até certo ponto. Mais algumas buscas no Google depois eu descobri que isso realmente era um bug no Ubuntu. link

Eu não achei que o whoopsie - daemon de submissão do banco de dados do Ubuntu - fosse necessário em meu servidor como um componente crítico. Fomos adiante e apt-get removeu os purgados os pacotes de todos os servidores.