Corrigindo falhas de página no MongoDB

As falhas de página são um erro predominante que ocorre principalmente em um grande aplicativo que envolve grandes volumes de dados. Ocorre quando o banco de dados MongoDB lê dados da memória física em vez da memória virtual. Erros de falha de página ocorrem no momento em que o MongoDB deseja obter dados que não estão disponíveis na memória ativa do banco de dados, portanto, forçados a ler do disco. Isso cria uma grande latência para as operações de taxa de transferência, fazendo com que as consultas pareçam estar atrasadas.

Ajustar o desempenho do MongoDB por meio do ajuste é um componente vital que otimiza a execução de um aplicativo. Os bancos de dados são aprimorados para trabalhar com informações mantidas no disco, porém, habitualmente, armazenam em cache grandes quantidades de dados na RAM na tentativa de acessar o disco. É caro armazenar e acessar dados do banco de dados, portanto, as informações devem ser armazenadas primeiro no disco antes de permitir que os aplicativos o acessem. Devido ao fato de que os discos são mais lentos em comparação com o cache de dados da RAM, o processo consome uma quantidade significativa de tempo. Portanto, o MongoDB foi projetado para relatar a ocorrência de falhas de página como um resumo de todos os incidentes em um segundo

A topologia de movimentação de dados no MongoDB

Os dados do cliente são movidos para a memória virtual, onde o cache da página os lê enquanto são gravados. Os dados são armazenados no disco conforme mostrado no diagrama abaixo.

Como encontrar falhas de página do MongoDB

As falhas de página podem ser detectadas por meio do desempenho de bloqueio que garante a consistência dos dados no MongoDB. Quando uma determinada operação enfileira ou é executada por um longo tempo, o desempenho do MongoDB diminui e a operação fica mais lenta enquanto aguarda o bloqueio. Isso leva a uma desaceleração, pois os atrasos relacionados ao bloqueio são esporádicos e às vezes afetam o desempenho do aplicativo. O bloqueio influencia o desempenho de um aplicativo quando os bloqueios são divididos (locks.timeAcquiringMicros por locks.acquireWaitCount), isso fornece o tempo médio de espera por um determinado modo de bloqueio. Locks.deadLockCount fornece o total de todos os impasses de aquisição de bloqueio experimentados. Dado que o globalLock.totalTime é harmoniosamente alto, há várias solicitações esperando um bloqueio. À medida que mais solicitações aguardam o bloqueio, mais RAM é consumida e isso leva a falhas de página.

Você também pode usar o mem.mapped, que permite aos desenvolvedores examinar a memória total que o mongod está utilizando. Mem.mapped é um operador de servidor para verificar a quantidade de memória em megabyte (MB) em um mecanismo de armazenamento MMAPv1. Se o operador mem.mapped mostrar um valor maior que a quantidade total de memória do sistema, ocorrerá uma falha de página porque uma quantidade tão grande de uso de memória levará a uma falha de página no banco de dados.

Como as falhas de página ocorrem no MongoDB

O carregamento de páginas no MongoDB depende da disponibilidade de memória livre, no caso de falta de memória livre, o sistema operacional precisa:

Procure uma página que o banco de dados deixou de usar e grave a página no disco de memória.
Carregue a página solicitada na memória depois de lê-la do disco.

Essas duas atividades ocorrem quando as páginas estão sendo carregadas e, portanto, consomem muito tempo em comparação com a leitura em uma memória ativa, levando à ocorrência de falhas de página.

Resolvendo falhas de página do MongoDB

A seguir estão algumas maneiras pelas quais se pode resolver falhas de página:

Escalonamento vertical para dispositivos com RAM suficiente ou escalonamento horizontal: quando não há RAM suficiente para um determinado conjunto de dados, a abordagem correta é aumentar a memória RAM dimensionando verticalmente para dispositivos com mais RAM para adicionar mais recursos ao servidor. O dimensionamento vertical é uma das melhores e mais fáceis maneiras de aumentar o desempenho do MongoDB ao não distribuir a carga entre vários servidores. Visto que o dimensionamento vertical adiciona mais RAM, o dimensionamento horizontal permite a adição de mais shards a um cluster shard. Em termos simples, o dimensionamento horizontal é onde o banco de dados é dividido em vários pedaços e armazenado em vários servidores. O dimensionamento horizontal permite que o desenvolvedor adicione mais servidores rapidamente e isso aumenta muito o desempenho do banco de dados, pois não incorre em tempo de inatividade zero. O dimensionamento vertical e o dimensionamento horizontal reduzem a ocorrência de falhas de página aumentando a memória que se trabalha ao trabalhar com o banco de dados.
Indexar dados corretamente: uso de índices apropriados para garantir que haja consultas eficientes que não causem verificações de coleção. A indexação adequada garante que o banco de dados não itere sobre cada documento em uma coleção e, assim, resolve a possível ocorrência de erro de falha de página. A varredura de coleção causa um erro de falha de página porque toda a coleção é inspecionada pelo mecanismo de consulta à medida que é lida na RAM. A maioria dos documentos na verificação de coleção não é retornada no aplicativo e, portanto, causa falhas de página desnecessárias para cada consulta subsequente que não é fácil de evitar. Além disso, o excesso de índices também pode levar ao uso ineficiente da RAM, o que pode levar a um erro de falha de página. Portanto, a indexação adequada é fundamental se um desenvolvedor pretende resolver erros de falha de página. O MongoDB oferece assistência na determinação dos índices que devem ser implantados ao usar o banco de dados. Eles oferecem o Slow Query Analyzer que fornece as informações necessárias sobre como indexar usuários e usuários compartilhados.
Migrando para a versão mais recente do MongoDB e movendo o aplicativo para o WiredTiger. Isso é necessário se você pretende evitar erros de falha de página, pois as falhas de página são comuns apenas nos mecanismos de armazenamento MMAPv1, em oposição às versões mais recentes e ao WiredTiger. O mecanismo de armazenamento MMAPv1 foi preterido e o MongoDB não o suporta mais. O WiredTiger é o mecanismo de armazenamento padrão atual no MongoDB e possui controle de simultaneidade de várias versões, o que o torna muito melhor em comparação com o mecanismo de armazenamento MMAPv1. Com o WiredTiger, o MongoDB pode usar o cache do sistema de arquivos e o cache interno do WiredTiger, que possui um tamanho muito grande de 1 GB (50% 0f ( RAM - 1 GB)) ou 256 MB.
Acompanhe o total de RAM disponível para uso em seu sistema. Isso pode ser feito usando serviços como o monitoramento da New Relic Google Cloud Monitoring. Além disso, o BindPlane pode ser utilizado com os serviços de monitoramento de nuvem mencionados. Usar um sistema de monitoramento é uma medida proativa que permite combater falhas de página antes que elas aconteçam, em vez de reagir a falhas de página que ocorrem. O BindPlane permite que o monitor configure alertas constantes para ocorrência de falhas de página, os alertas também informam o número de índices, o tamanho do índice e o tamanho do arquivo.
Garantir que os dados sejam configurados no conjunto de trabalho predominante e não usem mais RAM do que o recomendado. MongoDB é um sistema de banco de dados que funciona melhor quando dados e índices acessados com frequência podem caber perfeitamente na memória atribuída. O tamanho da RAM é um aspecto vital ao otimizar o desempenho do banco de dados, portanto, deve-se garantir que sempre haja memória RAM suficiente antes de implantar o aplicativo.
Distribuir carga entre instâncias do mongod adicionando fragmentos ou implantando um cluster fragmentado. É de vital importância permitir o sombreamento onde a coleção alvo está localizada. Primeiro, conecte-se aos mongos no shell do mongo e use o método abaixo.
1. ```
sh.shardCollection()
```
  Em seguida, crie um índice por este método.
```
db.collection.createIndex(keys, options)
```
  O índice criado suporta a chave de fragmentação, ou seja, se a coleção criada já tiver recebido ou armazenado alguns dados. No entanto, se a coleção não tiver dados (vazia), use o método abaixo para indexá-la como parte do ssh.shardCollection: sh.shardCollection()
2. Isso é seguido por uma das duas estratégias fornecidas pelo mongoDB.
  1. Sombreamento com hash
```
sh.shardCollection("<database>.<collection>", { <shard key field> : "hashed" } )
```
  2. Sombreamento baseado em intervalo
```
sh.shardCollection("<database>.<collection>", { <shard key field> : 1, ... } )
```

Como evitar falhas de página do MongoDB

Adicione fragmentos ou implante um cluster fragmentado para distribuir a carga
Tenha RAM suficiente para seu aplicativo antes de implantá-lo
Mover para as versões mais recentes do MongoDB e prosseguir para o WiredTiger
Escale vertical ou horizontalmente para um dispositivo com mais RAM
Use a RAM recomendada e acompanhe o espaço de RAM usado

Conclusão

Alguns poucos erros de página (sozinhos) demoram pouco, no entanto, em uma situação em que há vários erros de página (agregados), é uma indicação de que o banco de dados está lendo um grande número de dados em O disco. Quando a agregação ocorrer, haverá mais bloqueios de leitura do MongoBD que levarão a uma falha de página.

Ao usar o MongoDB, o tamanho da RAM do sistema e o número de consultas podem influenciar bastante o desempenho do aplicativo. O desempenho de um aplicativo no MongoDB depende muito da RAM disponível na memória física, o que afeta o tempo que o aplicativo leva para fazer uma única consulta. Com RAM suficiente, a ocorrência de falhas de página é reduzida e o desempenho do aplicativo é aprimorado.