Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/
Sistemas autogerenciados
/
Administração
/
Monitoramento

Perguntas frequentes: Diagnóstico autogerenciado do MongoDB

Nesta página

  • Onde posso encontrar informações sobre um processo do mongod que parou de ser executado inesperadamente?
  • O tempo de TCP keepalive afeta os sistemas do MongoDB?
  • Os tempos limite de retransmissão TCP afetam os sistemas MongoDB?
  • Por que o MongoDB registra tantos eventos de "Conexão aceita"?
  • Quais ferramentas estão disponíveis para monitorar o MongoDB?
  • Diagnóstico de memória para o mecanismo de armazenamento WiredTiger
  • Diagnóstico de clusters fragmentados

Este documento fornece respostas para questões e problemas comuns de diagnóstico.

Se você não encontrar a resposta que procura, consulte alista completa de Perguntas frequentes ou publique sua pergunta naMongoDB Community .

Onde posso encontrar informações sobre um mongod processo do que parou de ser executado inesperadamente?

Se mongod for desligado inesperadamente em uma plataforma UNIX ou baseada em UNIX e se mongod não registrar uma mensagem de desligamento ou de erro, verifique os registros do sistema para ver se há mensagens referentes ao MongoDB. Por exemplo, para logs localizados no /var/log/messages, utilize os seguintes comandos:

sudo grep mongod /var/log/messages
sudo grep score /var/log/messages

O keepalive tempo de TCP afeta deployments do MongoDB ?

Se você tiver tempo limite de rede ou erros de soquete na comunicação entre clientes e servidores, ou entre membros de um cluster fragmentado ou conjunto de réplicas, verifique o valor de manutenção de atividade do TCP para os sistemas afetados.

Por padrão, muitos sistemas operacionais definem esse valor como 7200 segundos (duas horas). Para o MongoDB, você geralmente obterá melhores resultados com um valor de keepalive mais curto, da ordem de 120 segundos (dois minutos).

Se seu sistema do MongoDB tiver problemas relacionados à manutenção de atividade, você deverá alterar o valor de manutenção de atividade em todos os sistemas afetados. Isso inclui todas as máquinas executando processos mongod ou mongos e todas as máquinas que hospedam processos clientes que se conectam ao MongoDB.

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

  • Para visualizar a configuração do keepalive no Linux, use um dos seguintes comandos:

    sysctl net.ipv4.tcp_keepalive_time

    Ou:

    cat /proc/sys/net/ipv4/tcp_keepalive_time

    O valor é medido em segundos.

    Observação

    Embora o nome da configuração inclua ipv4, o valor tcp_keepalive_time se aplica tanto a IPv4 quanto a IPv6.

  • Para alterar o tcp_keepalive_time valor de , pode utilizar um dos seguintes comandos, fornecendo um <value> em segundos:

    sudo sysctl -w net.ipv4.tcp_keepalive_time=<value>

    Ou:

    echo <value> | sudo tee /proc/sys/net/ipv4/tcp_keepalive_time

    Essas operações não persistem durante as reinicializações do sistema. Para persistir a configuração, adicione a seguinte linha a /etc/sysctl.conf, fornecendo um <value> em segundos, e reinicialize a máquina:

    net.ipv4.tcp_keepalive_time = <value>

    Valores de Keepalive maiores que 300 segundos (5 minutos) serão substituídos nos soquetes mongod e mongos e definidos como 300 segundos.

  • Para visualizar a configuração do keepalive no Windows, emita o seguinte comando:

    reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v KeepAliveTime

    O valor do registro não está presente por padrão. O padrão do sistema, usado se o valor estiver ausente, é 7200000 milissegundos ou 0x6ddd00 em hexadecimal.


  • Para alterar o valor do KeepAliveTime, utilize o seguinte comando em um Administrador Command Prompt, onde <value> é expresso em hexadecimal (por exemplo, 120000 é 0x1d4c0):

    reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ /t REG_DWORD /v KeepAliveTime /d <value>

    Os usuários do Windows devem considerar o Artigo técnico no Servidor do Windows no KeepAliveTime para obter mais informações sobre como configurar o keepalive para implantações do MongoDB em sistemas Windows. Os valores de keepalive maiores ou iguais a 600000 milésimos de segundo (10 minutos) serão ignorados por mongod e mongos.

  • Para visualizar a configuração do keepalive no macOS, emita o seguinte comando:

    sysctl net.inet.tcp.keepidle

    O valor é medido em milissegundos.


  • Para alterar o net.inet.tcp.keepidle valor do , você pode utilizar o seguinte comando, fornecendo um <value> em milissegundos:

    sudo sysctl net.inet.tcp.keepidle=<value>

    Essa operação não persiste durante as reinicializações do sistema e deve ser definida toda vez que o sistema for reiniciado. Consulte a documentação do seu sistema operacional para obter instruções sobre como definir esse valor persistentemente. Os valores de keepalive maiores ou iguais a 600000 milissegundos (10 minutos) serão ignorados por mongod e mongos.

    Observação

    No macOS 10.15 Catalina, a Apple não permite mais a configuração da opção net.inet.tcp.keepidle .

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

Os tempos limite de retransmissão TCP afetam os sistemas MongoDB?

Se você tiver longas paralisações (paralisações superiores a dois minutos) seguidas de tempos limite de rede ou erros de soquete entre clientes e servidores ou entre membros de um cluster fragmentado ou conjunto de réplicas, verifique o valor tcp_retries2 para os sistemas afetados.

A maioria dos sistemas operacionais Linux configura este valor como 15 por padrão, enquanto o Windows o configura como 5. Para MongoDB, você tem melhores resultados com um valor inferior a tcp_retries2, na ordem de 5 (12 segundos) ou inferior.

Se o sistema do MongoDB apresentar problemas relacionados ao tempo limite de retransmissão TCP, altere o valor tcp_retries2 (TcpMaxDataRetransmission no Windows) em todos os sistemas afetados. Isso inclui todos os computadores que executam processos mongod ou mongos e todos os computadores que hospedam processos de clientes que se conectam ao MongoDB.

Ajustar o tempo limite de retransmissão TCP

Na maioria dos sistemas operacionais Linux, controle a retransmissão TCP ajustando a configuração sysctl do net.ipv4.tcp_retries2.

Observação

Embora o nome da configuração inclua ipv4, a configuração tcp_retries2 se aplica tanto a IPv4 quanto a IPv6.

  • Para visualizar a configuração atual, use o comando sysctl:

    sysctl net.ipv4.tcp_retries2
    net.ipv4.tcp_retries = 15

  • Para alterar a configuração do tcp_retries2 em tempo de execução, use o comando sysctl:

    sysctl -w net.ipv4.tcp_retries2=8

  • Para tornar a alteração permanente, edite o arquivo de configuração:

    1. Abra /etc/sysctl.conf no seu editor de texto preferido:

      vi /etc/sysctl.conf

    2. Configure a definição net.ipv4.tcp_retries2:

      net.ipv4.tcp_retries2 = 8

    3. Reinicie o sistema.

    Seu sistema agora usa a nova configuração tcp_retries2.

No Windows, controle a retransmissão TCP ajustando o parâmetro TcpMaxDataRetransmissions .

  • Para visualizar a configuração do TcpMaxDataRetransmissions no Windows, emita o seguinte comando:

    reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v TcpMaxDataRetransmissions

    Por padrão, o parâmetro não está definido. O padrão do sistema, usado se o valor estiver ausente, é 5 tentativas.

  • Para alterar o valor do TcpMaxDataRetransmissions , utilize o seguinte comando em um Administrador Command Prompt, onde <value> é um número inteiro:

    reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ /t REG_DWORD /v TcpMaxDataRetransmission /d <value>

Por que o MongoDB registra tantos eventos de "Conexão aceita"?

Se você vir um número muito grande de mensagens de conexão e reconexão no log do MongoDB, isso significa que os clientes estão se conectando e desconectando com frequência do servidor MongoDB. Esse é o comportamento normal para aplicativos que não usam agrupamento de solicitações, como CGI. Considere o uso do FastCGI, de um módulo do Apache ou de algum outro tipo de servidor de aplicativos persistente para reduzir a sobrecarga de conexão.

Se estas conexões não afetarem seu desempenho, você poderá utilizar a opção de tempo de execução do quiet ou a opção de linha de comando --quiet para suprimir estas mensagens do log.

Quais ferramentas estão disponíveis para monitorar o MongoDB?

O MongoDB Cloud Manager e o Ops Manager, uma solução local disponível no MongoDB Enterprise Advanced incluem funcionalidade de monitoramento, que coleta dados da execução de implantações MongoDB e fornece visualização e alertas com base nesses dados.

Para obter mais informações, consulte também a documentação do MongoDB Cloud Manager e a documentação doOps Manager.

Uma lista completa de ferramentas de terceiros está disponível como parte da documentação Monitorando um sistema autogerenciado do MongoDB .

Diagnóstico de memória para o mecanismo de armazenamento WiredTiger

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

No.

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

Observação

O storage.wiredTiger.engineConfig.cacheSizeGB limita o tamanho do cache interno do WiredTiger. O sistema operacional usa a memória livre disponível para o cache do sistema de arquivos, o que permite que os arquivos de dados compactados do MongoDB permaneçam na memória. Além disso, o sistema operacional usa qualquer RAM livre para armazenar em buffer blocos do sistema de arquivos e cache do sistema de arquivos.

Para acomodar os consumidores adicionais de RAM, pode ser necessário diminuir o tamanho do cache interno do WiredTiger.

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 contêiner (por exemplo, lxc, cgroups, Docker etc.) que não tenha acesso a toda a RAM disponível em um sistema, será necessário definir storage.wiredTiger.engineConfig.cacheSizeGB como um valor menor que a quantidade de RAM disponível no contêiner. A quantidade exata depende dos outros processos em execução no contêiner. 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.

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 4 GB de RAM, o cache WiredTiger usa 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, o 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).

Observação

Em alguns casos, como quando executado em um container, o banco de dados pode ter restrições de memória inferiores à memória total do sistema. Nesses casos, esse limite de memória, em vez do total memória do sistema, é usado como a RAM máxima disponível.

Para ver o limite de memória, consulte hostInfo.system.memLimitMB.

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.

Observação

O storage.wiredTiger.engineConfig.cacheSizeGB limita o tamanho do cache interno do WiredTiger. O sistema operacional usa a memória livre disponível para o cache do sistema de arquivos, o que permite que os arquivos de dados compactados do MongoDB permaneçam na memória. Além disso, o sistema operacional usa qualquer RAM livre para armazenar em buffer blocos do sistema de arquivos e cache do sistema de arquivos.

Para acomodar os consumidores adicionais de RAM, pode ser necessário diminuir o tamanho do cache interno do WiredTiger.

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 contêiner (por exemplo, lxc, cgroups, Docker etc.) que não tenha acesso a toda a RAM disponível em um sistema, será necessário definir storage.wiredTiger.engineConfig.cacheSizeGB como um valor menor que a quantidade de RAM disponível no contêiner. A quantidade exata depende dos outros processos em execução no contêiner. Consulte memLimitMB.

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

Diagnóstico de clusters fragmentados

Os dois fatores mais importantes na manutenção de um cluster fragmentado bem-sucedido são:

Embora você possa alterar sua chave de fragmento posteriormente, é importante considerar cuidadosamente a escolha da chave de fragmento para evitar problemas de escalabilidade e desempenho. Continue lendo sobre problemas específicos que você pode encontrar em um ambiente de produção.

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:

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.

Voltar

Monitoramento

Próximo

Códigos de saída e status para um sistema autogerenciado