Perguntas frequentes: Diagnóstico do MongoDB

Ajustando o valor de manutenção de atividade TCP:

Você precisará reiniciar mongod e processos demongos para que as novas configurações de keepalive em todo o sistema entrem em vigor.

Ajustar o tempo limite de retransmissão TCP

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

Não.

Se o cache não tiver espaço suficiente para carregar dados adicionais, o WiredTiger evita páginas do cache para liberar espaço.

O valor padrão do tamanho do cache interno do WiredTiger pressupõe que haja uma única instância mongod por máquina. Se uma única máquina contiver várias instâncias do MongoDB, você deverá diminuir a configuração para acomodar as outras instâncias mongod.

Se você executar mongod em um container (por exemplo, lxc, cgroups, Docker, etc.) que não tem acesso a toda a RAM disponível em um sistema, você deverá definir storage.wiredTiger.engineConfig.cacheSizeGB para um valor menor que a quantidade de RAM disponível no container. A quantidade exata depende dos outros processos em execução no container. Consulte memLimitMB.

Para ver estatísticas sobre cache e despejo, use o comando serverStatus. O campo wiredTiger.cache contém as informações sobre cache e despejo.

...
"wiredTiger" : {
   ...
   "cache" : {
      "tracked dirty bytes in the cache" : <num>,
      "bytes currently in the cache" : <num>,
      "maximum bytes configured" : <num>,
      "bytes read into cache" :<num>,
      "bytes written from cache" : <num>,
      "pages evicted by application threads" : <num>,
      "checkpoint blocked page eviction" : <num>,
      "unmodified pages evicted" : <num>,
      "page split during eviction deepened the tree" : <num>,
      "modified pages evicted" : <num>,
      "pages selected for eviction unable to be evicted" : <num>,
      "pages evicted because they exceeded the in-memory maximum" : <num>,,
      "pages evicted because they had chains of deleted items" : <num>,
      "failed eviction of pages that exceeded the in-memory maximum" : <num>,
      "hazard pointer blocked page eviction" : <num>,
      "internal pages evicted" : <num>,
      "maximum page size at eviction" : <num>,
      "eviction server candidate queue empty when topping up" : <num>,
      "eviction server candidate queue not empty when topping up" : <num>,
      "eviction server evicting pages" : <num>,
      "eviction server populating queue, but not evicting pages" : <num>,
      "eviction server unable to reach eviction goal" : <num>,
      "pages split during eviction" : <num>,
      "pages walked for eviction" : <num>,
      "eviction worker thread evicting pages" : <num>,
      "in-memory page splits" : <num>,
      "percentage overhead" : <num>,
      "tracked dirty pages in the cache" : <num>,
      "pages currently held in the cache" : <num>,
      "pages read into cache" : <num>,
      "pages written from cache" : <num>,
   },
   ...

Para uma explicação de algumas estatísticas de evicção e cache da chave, como wiredTiger.cache.bytes currently in the cache e wiredTiger.cache.tracked dirty bytes in the cache, consulte wiredTiger.cache.

Para ajustar o tamanho do cache interno do WiredTiger, consulte storage.wiredTiger.engineConfig.cacheSizeGB e --wiredTigerCacheSizeGB. Evite aumentar o tamanho do cache interno do WiredTiger acima do valor padrão.

Como faço para calcular a quantidade de RAM necessária para meu aplicativo?

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

A partir do MongoDB 3.4, o tamanho do cache interno padrão do WiredTiger é o maior entre:

• 50% de (RAM - 1 GB) ou

• 256 MB.

Por exemplo, em um sistema com um total de 4GB de RAM, o cache WiredTiger utiliza 1.5GB de RAM (0.5 * (4 GB - 1 GB) = 1.5 GB). Por outro lado, em um sistema com um total de 1.25 GB de RAM WiredTiger aloca 256 MB para o cache do WiredTiger porque isso é mais da metade da RAM total menos um gigabyte (0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB).

Por padrão, o WiredTiger usa compressão de bloco Snappy para todas as collections e compactação de prefixo para todos os índices. Os padrões de compactação são configuráveis em nível global e também podem ser definidos por collection e por índice durante a criação da collection e do índice.

Diferentes representações são usadas para dados no cache interno do WiredTiger versus o formato no disco:

• Os ficheiros de dados no cache do sistema de arquivos são os mesmos do formato no disco, incluindo os benefícios de qualquer compactação para ficheiros de dados. O cache do sistema de arquivos é usado pelo sistema operacional para reduzir a E/S do disco.

• Os índices carregados no cache interno do WiredTiger têm uma representação de dados diferente do formato no disco, mas ainda podem aproveitar a compactação de prefixo do índice para reduzir o uso de RAM. A compactação de prefixo de índice deduplica prefixos comuns de campos indexados.

• Os dados de coleta no cache interno do WiredTiger são descompactados e utilizam uma representação diferente do formato no disco. A compactação de blocos pode proporcionar uma economia significativa de armazenamento em disco, mas os dados devem ser descompactados para serem manipulados pelo servidor.

Com o cache do sistema de arquivos, o MongoDB usa automaticamente toda a memória livre que não é usada pelo cache do WiredTiger ou por outros processos.

Para ajustar o tamanho do cache interno do WiredTiger, consulte storage.wiredTiger.engineConfig.cacheSizeGB e --wiredTigerCacheSizeGB. Evite aumentar o tamanho do cache interno do WiredTiger acima do valor padrão.

O valor padrão do tamanho do cache interno do WiredTiger pressupõe que haja uma única instância mongod por máquina. Se uma única máquina contiver várias instâncias do MongoDB, você deverá diminuir a configuração para acomodar as outras instâncias mongod.

Se você executar mongod em um container (por exemplo, lxc, cgroups, Docker, etc.) que não tem acesso a toda a RAM disponível em um sistema, você deverá definir storage.wiredTiger.engineConfig.cacheSizeGB para um valor menor que a quantidade de RAM disponível no container. A quantidade exata depende dos outros processos em execução no container. Consulte memLimitMB.

Para exibir estatísticas sobre o cache e a taxa de despejo, consulte o campo wiredTiger.cache retornado pelo comando serverStatus.

Em um novo cluster fragmentado, por que todos os dados permanecem em um fragmento?

Seu cluster deve ter dados suficientes para que a fragmentação faça sentido. A fragmentação migra chunks entre os shards até que cada shard tenha aproximadamente o mesmo número de chunks.

O tamanho padrão do chunk é de 128 megabytes. O MongoDB não iniciará migrações até que o desequilíbrio de chunks no cluster exceda o limite de migração. Esse comportamento ajuda a evitar migrações de chunks desnecessárias, que podem degradar o desempenho do cluster como um todo.

Se você acabou de implementar um cluster fragmentado, certifique-se de ter dados suficientes para tornar o compartilhamento eficaz. Se você não tiver dados suficientes para criar mais de oito blocos de 128 megabytes, todos os dados permanecerão em um fragmento. Reduza a configuração de tamanho do chunk ou adicione mais dados ao cluster.

Como um problema relacionado, o sistema dividirá blocos somente em inserções ou atualizações, o que significa que, se você configurar o sharding e não continuar a emitir operações de inserção e atualização, o banco de dados não criará blocos. Você pode esperar até que o aplicativo insira os dados ou dividir os blocos manualmente.

Finalmente, se sua chave de shard tiver uma cardinalidade baixa, o MongoDB pode não ser capaz de criar splits suficientes entre os dados.

Por que um fragmento receberia uma quantidade desproporcional de tráfego em um cluster fragmentado?

Em algumas situações, um único shard ou um subconjunto do cluster receberá uma porção desproporcional do tráfego e volume de trabalho. Em quase todos os casos, esse é o resultado de uma chave de shard que não permite efetivamente o dimensionamento de gravação.

Também é possível que você tenha “pedaços quentes”. Nesse caso, você poderá resolver o problema dividindo e migrando partes desses blocos.

Talvez seja necessário reestruturar sua coleção com uma chave de fragmento diferente para corrigir esse padrão.

O que pode impedir o equilíbrio de um cluster fragmentado?

Se você acabou de implantar seu cluster fragmentado, convém considerar as sugestões de solução de problemas para um novo cluster em que os dados permanecem em um único fragmento.

Se o cluster foi inicialmente equilibrado, mas mais tarde desenvolveu uma distribuição irregular de dados, considere as seguintes causas possíveis:

• Você excluiu ou removeu uma quantidade significativa de dados do cluster. Se você tiver adicionado dados adicionais, eles poderão ter uma distribuição diferente com relação à chave de fragmento.

• Sua chave de fragmento tem baixa cardinalidade e o MongoDB não pode mais dividir os pedaços.

• Seu conjunto de dados está crescendo mais rápido do que o balancer consegue distribuir dados ao redor do cluster. Isso não comum, e normalmente é o resultado de:

  • uma janela de balanceamento muito curta, dada a taxa de crescimento dos dados.

  • uma distribuição irregular de operações de gravação que exige mais migração de dados. Talvez seja necessário escolher uma chave de shard diferente para resolver esse problema.

  • Conectividade de rede ruim entre fragmentos, o que pode levar a migrações de blocos que levam muito tempo para serem concluídas. Investigue sua configuração de rede e interconexões entre fragmentos.

Por que migrações de chunks afetam o desempenho do cluster fragmentado?

Se as migrações afetarem o desempenho do cluster ou do aplicativo, considere as seguintes opções, dependendo da natureza do impacto:

1. Se as migrações interromperem seus clusters apenas esporadicamente, você poderá limitar a janela de balanceamento para evitar a atividade de balanceamento durante os horários de pico. Certifique-se de que ainda haja tempo suficiente para evitar que os dados fiquem desequilibrados novamente.

2. Se o balanceador estiver sempre migrando pedaços para o detrimento do desempenho geral do cluster:

   • Talvez você queira tentar diminuir o tamanho do chunk para limitar o tamanho da migração.

   • Seu cluster pode estar acima da capacidade e talvez você queira tentar adicionar um ou dois fragmentos ao cluster para distribuir carga.

Também é possível que sua chave de fragmento faça com que sua aplicação direcione todos os escritos para um único fragmento. Esse tipo de padrão de atividade pode exigir que o balanceador migre a maioria dos dados logo após gravá-los. Talvez seja necessário considerar a refragmentação de sua coleção com uma chave de fragmento diferente que forneça melhor dimensionamento de gravação.