mongodb wiredtiger engine de ext4 para xfs

Question

Estou com problemas de desempenho relacionados ao mecanismo mongodb wiredtiger em um sistema de arquivos ext4 ( link )

Eu tenho um replicaset com 2 servidores e um arbitrador (todos no ext4).

Eu gostaria de saber se existe algum problema para adicionar um novo servidor a este replicaset com um sistema de arquivos diferente (no meu caso XFS), a idéia é adicionar novos secundários XFS e promover um para primário antes de fechar o antigo aqueles que estão no ext4.

    

Answer 1

Os membros do conjunto de réplicas podem usar sistemas de arquivos diferentes - os membros nem sabem quais sistemas de arquivos estão sendo usados por seus colegas.

Embora o uso do sistema de arquivos Ext4 seja uma possibilidade para problemas de desempenho com o MongoDB e o WiredTiger (particularmente sob carga de gravação significativa), pode haver outros problemas afetando o seu caso de uso. Detalhes como a versão específica do servidor MongoDB, a versão O / S, os avisos de inicialização e quaisquer mensagens de log correlacionadas ao período de desaceleração podem fornecer mais informações se você decidir postar uma pergunta de acompanhamento para investigar seu problema de desempenho periódico. Outros detalhes de implantação, como hospedagem (bare metal vs nuvem), recursos de recursos do servidor (RAM, CPU, tipo de disco) e alterações de configuração mongod também podem ser relevantes.

Como você suspeita de um problema de desempenho relacionado ao uso do Ext4, eu tentaria isolar as alterações na sua implantação do MongoDB para tentar confirmar essa teoria (especialmente se suas paralisações periódicas forem consistentemente reproduzíveis):

• Se você vir apenas paralisações periódicas em um membro do conjunto de réplicas (por exemplo, o principal), tente reduzir o primário atual para que os membros substituam as funções. E / S lenta / insuficiente (ou vizinho barulhento em um ambiente de hospedagem em nuvem / compartilhado) às vezes pode ser o culpado. Você também pode descobrir que há algum outro fator baseado na função do membro (por exemplo, se seu aplicativo estiver lendo de secundários).
• Se você observar paralisações periódicas em ambos os membros atuais portadores de dados, adicione um novo membro usando XFS para o storage.dbPath para testar se esse novo membro exibe o mesmo comportamento.
• Se você ainda não estiver executando a versão secundária mais recente da sua versão do MongoDB, faça upgrade. Por exemplo, se você estiver executando o MongoDB 3.4.2 e a versão mais recente do 3.4.x disponível for 3.4.10, valeria a pena testar a mais nova versão estável. Os upgrades dentro da mesma série de lançamentos de produção incluem correções de bugs e melhorias de estabilidade, mas não devem introduzir nenhuma alteração de compatibilidade.

Outras sugestões:

• Revise os logs do MongoDB para qualquer atividade suspeita ou mensagens de log que possam estar correlacionadas a períodos de lentidão ou paralisações. Por exemplo, a tarefa de expiração do índice TTL (Time-To-Live) é executada a cada 60 segundos e pode excluir um número significativo de documentos. Pode haver consultas lentas ou outros avisos relevantes registrados.
• Supondo que você tenha algum monitoramento de métrica em vigor, analise as métricas de sua implantação do MongoDB para procurar valores discrepantes ou padrões que coincidam com seus períodos de desempenho insatisfatório.
• Se você estiver executando mais do que alguns lançamentos importantes por trás da série de lançamentos de produção mais recente do MongoDB, considere testar uma atualização de versão principal em um ambiente de preparação / desenvolvimento representativo. Houve melhorias significativas nos principais lançamentos sucessivos.
• Para obter informações gerais sobre o ajuste de implantações, também vale a pena revisar as Notas de Produção do MongoDB .