Performance MongoDB – Melhores práticas – 01 -Arquitetura NUMA

Iremos abordar um assunto que particularmente eu gosto bastante. Performance.

Quebraremos em séries para que não fique cansativo a leitura, mas, lembrando que precisamos olhar para todo o conjunto.

Nas séries, falaremos de práticas utilizadas para um melhor aproveitamento da instância de banco de dados MongoDB tanto a nível de sistema operacional quanto da própria base de dados.

Começaremos pela ARQUITETURA NUMA

Parece um pouco complexo até que se entenda sua real abordagem.

Non-uniform memory access (NUMA) tecnologia no mundo dos sistemas multiprocessados.

Neste sistema, as CPUs estão organizadas em conjuntos chamados de Nodes. Como podemos ver na imagem ao lado, cada node possui seu conjunto de pool de memória e processadores.

Vamos exemplificar. Na imagem a cima possuímos o total de 2 processadores físicos, 8 núcleos e 64 GB de memória RAM. Cada processador com os seus 4 núcleos e 32 GB de RAM formam um nó NUMA.  Para obter um uso mais eficiente precisamos garantir que a maquina virtual caiba dentro do tamanho do nó NUMA, ou seja, se uma VM com a configuração inferior a 32 GB de RAM e 4 vCPU for criada, o sistema operacional fará uso de um único nó NUMA e terá o acesso a memória localmente. Mas, se obtivermos um upgrade de memória ou vCPU (ficando superior ao tamanho do nó NUMA) na VM, então outro nó NUMA será criado e o acesso deixará de ser local. Neste caso mesmo tendo mais recursos de hardware esta VM poderá ter desempenho inferior ao da configuração anterior.

Você deve estar se perguntando, qual o ganho?
Vamos pensar em ambientes críticos. Arquitetura Summetric Multiprocessor (SMP) “mais tradicional”, apenas um processador tem acesso a memória num determinado momento. Ou seja, quanto mais processadores são adicionados, mais sobrecarregado fica o barramento de acesso à memória, o que poderá ser um fator limitante para a performance do serivdor.

Na arquitetura NUMA, como estão em pequenos conjunto de recursos e conectados ao um sistema maior através de barramento de alta velocidade, você acaba diminuindo a sobrecarga no acesso ao barramento de memória. A arquitetura não é uniforme pos cada processador está mais próximo a certas partes da memória do que de outras.

Mass, vamos falar do MongoDB. MongoDB não reconhece NUMA e o mesmo pode alocar memória de maneira desigual entre Nodes o que leva a problema de troca mesmo com a memória disponível. Para contornar o problema, o processo de mongod pode usar o modo intercalado das seguintes maneiras:

(Considerando que seu sistema está com arquitetura NUMA ativado)

Inicie o proceso mongod com numactl –interleavel=all:

Shell:

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

ou utilize o systemd:

1
2
# Edit the file
/etc/systemd/system/multi-user.target.wants/mongod.service

Se a ExecStart instrução existente exibir:

1ExecStart=/usr/bin/mongod –config /etc/mongod.conf

Atualize a declaração:

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

Aplique a alteração a systemd:

1sudo systemctl daemon-reload

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

Shell

1
2
sudo systemctl stop mongod
sudo systemctl start mongod

Agora é só validar:

1$ sudo numastat -p $(pidof mongod) 

CONCLUSÃO:

Podemos ter um grande aproveitamento de recurso e liberar um gargalo na troca de barramento com sistemas NUMA, mas, lembrando que é uma abordagem bem sensível e que exigirá um pouco mais da sua administração. Recomendável para sistemas de alta critícidade que exigem alto desempenho de ativos dos servidores.

Marcado com: ,
Publicado em NoSQL

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

Arquivos
Follow SQL DATA BLOG on WordPress.com
Mais acessados
  • Nenhum
%d blogueiros gostam disto: