Notas de produção para implantações autogerenciadas

wiredTiger

O mecanismo de armazenamento do WiredTiger é multithread e pode aproveitar os núcleos adicionais da CPU. Especificamente, o número total de threads ativos (ou seja, operações simultâneas) em relação ao número de CPUs disponíveis pode afetar o desempenho:

• O rendimento aumenta à medida que o número de operações ativas simultâneas aumenta até o número de CPUs.

• A taxa de transferência diminui à medida que o número de operações ativas simultâneas excede o número de CPUs em algum limite.

O limite depende do seu aplicativo. Você pode determinar o número ideal de operações ativas simultâneas para o seu aplicativo experimentando e medindo a taxa de transferência. O resultado de mongostat fornece estatísticas sobre o número de leituras/gravações ativas na coluna (ar|aw).

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).

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 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.

Compressão e criptografia

Ao usar criptografia, CPUs equipadas com extensões de conjunto de instruções AES-NI mostram vantagens significativas de desempenho. Se estiver usando o MongoDB Enterprise com o mecanismo de armazenamento criptografado, escolha uma CPU compatível com AES-NI para obter melhor desempenho.

Configuração do NUMA no Windows

No Windows, o intercâmbio de memória deve ser habilitado através do BIOS da máquina. Consulte a documentação do sistema para obter detalhes.

Configuração do NUMA no Linux

No Linux, você deve desativar a zone reclaim e também garantir que suas instâncias demongod e mongos sejam started by numactl, que geralmente é configurado por meio do sistema de inicialização da sua plataforma. Você deve executar ambas as operações para desabilitar adequadamente o NUMA para uso com MongoDB.

1. Desative a reclamação de zona com um dos seguintes comandos:

   echo 0 | sudo tee /proc/sys/vm/zone_reclaim_mode

   sudo sysctl -w vm.zone_reclaim_mode=0

2. Certifique-se de quemongod e mongos sejam iniciados por numactl. Isso geralmente é configurado por meio do sistema de inicialização da sua plataforma. Execute o seguinte comando para determinar qual sistema de inicialização está em uso na sua plataforma:

   ps --no-headers -o comm 1

   • Se "systemd", sua plataforma usa o sistema de entrada systemd e você deve seguir as etapas na aba systemd abaixo para editar seu(s) arquivo(s) de serviço MongoDB.

   • Se "init", sua plataforma usa o sistema SysV Init e você não precisa executar esta etapa. O script de inicialização padrão do MongoDB para SysV Init inclui as etapas necessárias para iniciar instâncias do MongoDB via numactl por padrão.

   • Se você gerencia seus próprios scripts de inicialização (ou seja, se não estiver usando nenhum desses sistemas de inicialização), siga as etapas da guia Scripts de inicialização personalizados abaixo para editar o(s) script(s) de inicialização personalizado(s).

     
     
   systemd

   Scripts de inicialização personalizados

   Você deve usar numactl para iniciar cada uma de suas mongod instâncias, incluindo todos os servidores de configuração, mongos instâncias e clientes. Edite o arquivo de serviço systemd padrão para cada um dos seguintes itens:

   1. Copie o arquivo de serviço MongoDB padrão:

      sudo cp /lib/systemd/system/mongod.service /etc/systemd/system/

   2. Edite o arquivo /etc/systemd/system/mongod.service e atualize a declaração ExecStart para começar com:

      /usr/bin/numactl --interleave=all

      Exemplo

      Se sua instrução ExecStart existente for:

      ExecStart=/usr/bin/mongod --config /etc/mongod.conf

      Atualize essa declaração para ler:

      ExecStart=/usr/bin/numactl --interleave=all /usr/bin/mongod --config /etc/mongod.conf

   3. Aplique a alteração a systemd:

      sudo systemctl daemon-reload

   4. Reinicie todas as instâncias mongod em execução:

      sudo systemctl stop mongod
      sudo systemctl start mongod

   5. Se aplicável, repita estas etapas para quaisquer instâncias do mongos.

   Você deve usar numactl para iniciar cada uma de suas mongod instâncias, incluindo todos os servidores de configuração, mongos instâncias e clientes.

   1. Instale o numactl para sua plataforma, se ainda não estiver instalado. Consulte a documentação do sistema operacional para obter informações sobre como instalar o pacote numactl.

   2. Configure cada um dos seus scripts de inicialização personalizados para iniciar cada instância do MongoDB via numactl:

      numactl --interleave=all <path> <options>

      Onde <path> é o caminho para o programa que você está iniciando e <options> quaisquer argumentos opcionais para passar para esse programa.

      Exemplo

      numactl --interleave=all /usr/local/bin/mongod -f /etc/mongod.conf

Para obter mais informações, consulte a Documentação para /proc/sys/vm/*.

Swap

O MongoDB tem melhor desempenho quando a troca pode ser evitada ou reduzida ao mínimo, pois a recuperação de dados da troca sempre será mais lenta do que acessar dados na RAM. No entanto, se o sistema que hospeda o MongoDB ficar sem RAM, a troca pode impedir que o Linux OOM Killer encerre o processomongod.

Geralmente, você deve escolher uma das seguintes estratégias de troca:

1. Atribua espaço de troca em seu sistema e configure o kernel para permitir apenas a troca sob alta carga de memória, ou

2. Não atribua espaço de troca no seu sistema e configure o kernel para desabilitar totalmente a troca

Consulte Set vm.swappiness para obter instruções sobre como configurar a troca em seu sistema Linux seguindo estas diretrizes.

RAID

Para obter desempenho ideal em termos de camada de armazenamento, use discos suportados por RAID-10. RAID-5 e RAID-6 normalmente não fornecem desempenho suficiente para suportar uma implantação do MongoDB.

Sistemas de arquivos remotos (NFS)

Com o mecanismo de armazenamento WiredTiger, os objetos WiredTiger podem ser armazenados em sistemas de arquivos remotos se o sistema de arquivos remoto estiver em conformidade com a ISO/IEC 9945-1:1996 (POSIX.1). Como os sistemas de arquivos remotos geralmente são mais lentos do que os sistemas de arquivos locais, o uso de um sistema de arquivos remoto para armazenamento pode prejudicar o desempenho.

Se você decidir utilizar o NFS, adicione as seguintes opções de NFS ao seu arquivo /etc/fstab:

• bg

• hard

• nolock

• noatime

• nointr

Dependendo da versão do seu kernel, alguns desses valores podem já ser definidos como padrão. Consulte a documentação da sua plataforma para obter mais informações.

Separe componentes em diferentes dispositivos de armazenamento

Para melhorar o desempenho, considere separar os dados, o diário e os logs do banco de dados em diferentes dispositivos de armazenamento, com base no padrão de acesso e gravação do aplicativo. Monte os componentes como sistemas de arquivos separados e use links simbólicos para mapear o caminho de cada componente até o dispositivo que o armazena.

Para o mecanismo de armazenamento WiredTiger, você também pode armazenar os índices em um dispositivo de armazenamento diferente. Consulte storage.wiredTiger.engineConfig.directoryForIndexes.

Agendamento

Sistemas de arquivos e kernel

Ao executar o MongoDB em produção no Linux, você deve usar o Linux kernel versão 2,6,36 ou posterior, com o sistema de arquivos XFS ou EXT4. Se possível, use o XFS, pois ele geralmente tem melhor desempenho com o MongoDB.

Com o mecanismo de armazenamento WiredTiger, o uso do XFS é altamente recomendado para nós de suporte de dados para evitar problemas de desempenho que podem ocorrer ao usar o EXT4 com o WiredTiger .

• Em geral, se você usa o sistema de arquivos XFS, use pelo menos a versão 2.6.25 do Linux Kernel.

• Se você usar o sistema de arquivos EXT4, use pelo menos a versão 2.6.28 do Linux Kernel.

• No Red Hat Enterprise Linux e CentOS, use pelo menos a versão 2.6.18-194 do Linux Kernel.

Biblioteca do Sistema C

O MongoDB utiliza a GNU C Library (glibc) no Linux. Geralmente, cada Linux distro fornece sua própria versão verificada desta biblioteca. Para melhores resultados, use a atualização mais recente disponível para esta versão fornecida pelo sistema. Você pode verificar se tem a versão mais recente instalada usando o gerenciador de pacotes do sistema. Por exemplo:

• Em RHEL / CentOS, o comando a seguir atualiza a Biblioteca GNU C fornecida pelo sistema:

  sudo yum update glibc

• No Ubuntu / Debian, o comando a seguir atualiza a biblioteca GNU C fornecida pelo sistema:

  sudo apt-get install libc6

fsync() em Diretórios

Definir vm.swappiness como 1 ou 0

“Swappiness” é uma configuração do kernel Linux que influencia o comportamento do gerenciador de memória virtual. A configuração vm.swappiness varia de 0 a 100: quanto maior o valor, mais fortemente ela prefere trocar páginas de memória para o disco em vez de remover páginas da RAM.

• Uma configuração de 0 desabilita totalmente a troca [4].

• Uma configuração de 1 permitir que o kernel seja trocado apenas para evitar problemas de falta de memória.

• Uma configuração do 60 disser ao kernel para trocar para disco frequentemente, e for o valor padrão em muitas distribuições Linux.

• Uma configuração de 100 disser ao kernel para trocar agressivamente para o disco.

O MongoDB tem melhor desempenho onde a troca pode ser evitada ou reduzida ao mínimo. Como tal, você deve definir vm.swappiness para 1 ou 0 dependendo das necessidades do aplicativo e da configuração do cluster.

• Para verificar a configuração atual de troca em seu sistema, execute:

  cat /proc/sys/vm/swappiness

• Para alterar a troca em seu sistema:

  1. Edite o arquivo /etc/sysctl.conf e adicione a seguinte linha:

     vm.swappiness = 1

  2. Execute o seguinte comando para aplicar a configuração:

     sudo sysctl -p

Configuração recomendada

Para todas as implantações do MongoDB:

• Use o Network Time Protocol (NTP) para sincronizar o tempo entre seus hosts. Isso é especialmente importante em agrupamentos fragmentados.

Para os mecanismos de armazenamento WiredTiger, considere as seguintes recomendações:

• Desative o atime para o volume de armazenamento que contém os arquivos do banco de dados.

• Ajuste as configurações do ulimit para sua plataforma de acordo com as recomendações na referência ulimit. Valores baixos de ulimit afetarão negativamente o MongoDB quando ele estiver sendo usado intensamente e podem levar a falhas nas conexões com os processos do MongoDB e à perda de serviço.

  Observação

  Se o valor ulimit para o número de arquivos abertos estiver em 64000, o MongoDB gerará um aviso de inicialização.

• Desative páginas enormes transparentes. O MongoDB tem melhor desempenho com páginas normais de memória virtual (4.096 bytes). Consulte Configurações de páginas enormes transparentes.

• Desative o NUMA em seu BIOS. Se isso não for possível, consulte MongoDB em hardware NUMA.

• Configure o SELinux para o MongoDB se não estiver usando os caminhos de diretório ou as portaspadrão do MongoDB .

  Consulte: Configurar o SELinux para MongoDB e Configurar o SELinux para MongoDB Enterprise para a configuração necessária.

  Observação

  Se você estiver usando o SELinux, qualquer operação do MongoDB que exija JavaScript no lado do servidor resultará em erros de segfault. Desativar execução de JavaScript no servidor descreve como desativar a execução de JavaScript no servidor.

Para o mecanismo de armazenamento WiredTiger:

• Defina a configuração de leitura entre 8 e 32, independentemente do tipo de mídia de armazenamento (disco giratório, SSD, etc.).

  Maior leitura antecipada geralmente beneficia operações de E/S sequenciais. Como os padrões de acesso ao disco do MongoDB são geralmente aleatórios, o uso de configurações de leitura mais altas fornece benefício limitado ou possível degradação do desempenho. Como tal, para um desempenho ideal do MongoDB, defina a leitura antecipada entre 8 e 32, a menos que o teste mostre um benefício mensurável, repetível e confiável em um valor de leitura mais alto. O suporte comercial do MongoDB pode fornecer conselhos e orientações sobre configurações alternativas de leitura antecipada.

Bibliotecas de TLS/SSL e MongoDB

Em plataformas Linux, você pode observar uma das seguintes afirmações no log MongoDB:

<path to TLS/SSL libs>/libssl.so.<version>: no version information available (required by /usr/bin/mongod)
<path to TLS/SSL libs>/libcrypto.so.<version>: no version information available (required by /usr/bin/mongod)

Esses avisos indicam que as bibliotecas TLS/SSL do sistema são diferentes das bibliotecas TLS/SSL em que o mongod foi compilado. Normalmente, essas mensagens não requerem intervenção; no entanto, você pode usar as seguintes operações para determinar as versões de símbolo que mongod espera:

objdump -T <path to mongod>/mongod | grep " SSL_"
objdump -T <path to mongod>/mongod | grep " CRYPTO_"

Essas operações retornarão a saída que se assemelha a uma das seguintes linhas:

0000000000000000      DF *UND*       0000000000000000  libssl.so.10 SSL_write
0000000000000000      DF *UND*       0000000000000000  OPENSSL_1.0.0 SSL_write

As duas últimas strings nesta saída são a versão do símbolo e o nome do símbolo. Compare estes valores com os valores retornados pelas seguintes operações para detectar incompatibilidade de versão de símbolo:

objdump -T <path to TLS/SSL libs>/libssl.so.1*
objdump -T <path to TLS/SSL libs>/libcrypto.so.1*

Esse procedimento não é exato nem exaustivo: muitos símbolos usados por mongod da biblioteca libcrypto não começam com CRYPTO_.

AWS EC2

Existem duas configurações de desempenho a serem consideradas:

• Desempenho reproduzível para testes de desempenho ou benchmarking, e

• Desempenho máximo bruto

Para ajustar o desempenho no EC2 para qualquer configuração, você deve:

• Ative o AWS Enhanced Networking para sua instância. Nem todos os tipos de instância oferecem suporte à rede aprimorada.

  Para saber mais sobre redes aprimoradas, consulte a documentação da AWS .

Se você estiver mais preocupado com o desempenho reproduzível no EC2, também deverá fazê-lo:

• Use IOPS provisionadas para o armazenamento, com dispositivos separados para registro e dados. Não use o armazenamento efêmero (SSD) disponível na maioria dos tipos de instância, pois seu desempenho muda a cada momento. (A série i é uma exceção notável, mas é muito cara).

• Desative os modos de economia de energia DVFS e CPU.

  Dica

  Veja também:

  Documentação da Amazon sobre o Controle do Estado do Processador

• Desativar o hyperthreading.

  Dica

  Veja também:

  Postagem no blog da Amazon sobre a desativação do Hyper-Threading.

• Use numactl para vincular a localidade da memória a um único soquete.

Azure

Use o Armazenamento Premium. O Microsoft Azure oferece dois tipos gerais de armazenamento: armazenamento padrão e armazenamento Premium. O MongoDB no Azure tem melhor desempenho ao usar o armazenamento Premium do que com o armazenamento Standard.

O tempo limite ocioso do TCP no balanceador de carga do Azure é de 240 segundos por padrão, o que pode fazer com que ele desca silenciosamente as conexões se a manutenção do TCP em seus sistemas do Azure for maior que esse valor. Você deve definir tcp_keepalive_time como 120 para melhorar esse problema.

• 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 Windows Server Technet 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 milissegundos (10 minutos) serão ignorados por mongod e mongos.

VMware

O MongoDB é compatível com VMware.

O VMware suporta compromisso de memória, onde você pode atribuir mais memória às suas máquinas virtuais do que a máquina física está disponível. Quando a memória está sobrecarregada, o hipervisor realoca a memória entre as máquinas virtuais. O driver de balão da VMware (vmmemctl) recupera as páginas consideradas menos valiosas.

O driver balão reside dentro do sistema operacional convidado. Sob certas configurações, quando o driver balão se expande, ele pode interferir no gerenciamento de memória do MongoDB e afetar o desempenho do MongoDB.

Para evitar o impacto negativo no desempenho do driver balão e dos recursos de comprometimento excessivo de memória, reserve a quantidade total de memória para a máquina virtual que executa o MongoDB. A reserva da quantidade apropriada de memória para a máquina virtual evita que o balão se infle no sistema operacional local se houver pressão por memória no hipervisor.

Mesmo que o driver balão e os recursos de superalocação de memória possam afetar negativamente o desempenho do MongoDB sob determinadas configurações, não desabilite esses recursos. Se você desabilitar esses recursos, o hipervisor poderá usar seu espaço de troca para atender às solicitações de memória, o que afetará negativamente o desempenho.

Certifique-se de que as máquinas virtuais permaneçam em um host ESX/ESXi específico definindo as regras de afinidade do VMware. Se você precisar migrar manualmente uma máquina virtual para outro host e a instância do mongod na máquina virtual for o primário, antes será necessário fazer step down no primário e depois shut down the instance.

Siga as melhores práticas de rede para vMotion e VMKernel. O não cumprimento das melhores práticas pode resultar em problemas de desempenho e afetar os mecanismos de alta disponibilidade do definir e do cluster fragmentado .

É possível clonar uma máquina virtual executando o MongoDB. Você pode usar essa função para ativar um novo host virtual para adicionar como membro de um conjunto de réplicas. Se você clonar uma VM com o registro no diário ativado, o instantâneo do clone será válido. Se não estiver usando mongod o registro no diário, primeiro interrompa , depois clone a VM e, finalmente, reinicie mongod.

KVM

O MongoDB é compatível com KVM.

O KVM oferece suporte ao comprometimento excessivo de memória, onde você pode atribuir mais memória às máquinas virtuais do que a máquina física tem disponível. Quando a memória está sobrecarregada, o hipervisor realoca a memória entre as máquinas virtuais. O driver de balão da KVM recupera as páginas consideradas menos valiosas.

O driver balão reside dentro do sistema operacional convidado. Sob certas configurações, quando o driver balão se expande, ele pode interferir no gerenciamento de memória do MongoDB e afetar o desempenho do MongoDB.

Para evitar o impacto negativo no desempenho do driver balão e dos recursos de comprometimento excessivo de memória, reserve a quantidade total de memória para a máquina virtual que executa o MongoDB. A reserva da quantidade apropriada de memória para a máquina virtual evita que o balão se infle no sistema operacional local se houver pressão por memória no hipervisor.

Mesmo que o driver balão e os recursos de superalocação de memória possam afetar negativamente o desempenho do MongoDB sob determinadas configurações, não desabilite esses recursos. Se você desabilitar esses recursos, o hipervisor poderá usar seu espaço de troca para atender às solicitações de memória, o que afetará negativamente o desempenho.