por favor explique essas estatísticas mongo

Question

Minha configuração: Eu tenho 2 hosts e 2 shards cada.

• O Host1 tem 2 fragmentos e é o mestre das réplicas
• o host2 tem os secundários dos dois fragmentos.

.

• host1: shard1 (repset1), shard2 (repset2)
• host2: shard1 (repset1), shard2 (repset2)

Há também um terceiro host que atua como árbitro.

Eu tenho 50 threads escrevendo aleatoriamente para ambos os shards (usando um hash) via mongos com REPLICA_SAFE WriteConcern definido em cada inserção.

As perguntas:

O
1. mongostat exibe cerca de 90% bloqueado para os dois shards no host1 e cerca de 1% para o host2. Como eu uso o REPLICA_SAFE que supostamente grava em ambos os servidores, os bloqueios não deveriam ser os mesmos?
2. mongostat reporta qr = 30 para os dois shards de host1 e qw = 0 sempre. Desde que eu executo apenas escreve como isso é possível? Além disso, no host2, todas as filas são relatadas. 0. As falhas são sobre as mesmas em todos os shards / hosts (arroba 80).
3. netIn / netOut nos secundários (host2) são sempre cerca de 200 bytes / seg. Muito baixo.
4. mongos tem 53 conexões, os shards do host1 têm 71 e 71 e os shards do host2 têm 9 e 8. Como isso é?

Answer 1

Tenha cuidado ao executar várias instâncias do mongod em um host. Eles estão competindo na unitização do sistema:

• Requisitos do Replicaset
• Pergunta dos Grupos do Google sobre instâncias concorrentes

Ou execute VMs com RAM e CPU dedicadas (essa é a maneira que você pode usar o 24Core System de maneira mais eficiente com o MongoDB;)

    

Answer 2

Sivann,

Parece que você está usando o mongo < 2.0 se você não for, isso pode mudar as coisas. Você diz que está usando o REPLICA_SAFE, qual nível de W está usando? Se for w: 1, então você está simplesmente confirmando que as gravações do seu primário foram bem-sucedidas, você deve usar w: 2 para confirmar que as gravações atingiram o seu secundário.

1. A replicação será responsável por isso. Suas inserções estão tomando um bloqueio de gravação conforme elas são inseridas e isso está impedindo a replicação de ler os dados para replicar.

2. Reforça o ponto 1. Suas leituras de replicação estão enfileiradas atrás das gravações das inserções. Falhas são provavelmente o problema aqui, já que o seu sistema precisa mapear para a RAM coisas que devem ser lidas para replicação que está produzindo seu bloqueio. Também é provável que você esteja vendo a disputa entre suas duas primárias pela RAM pelas razões mencionadas por Marc.

3. Parece baixo, mas não pode ser certo. É provável que seus sistemas estejam aguardando para enviar dados para a RAM ou para um bloqueio de gravação para replicá-los.

4. Você pode ver quais conexões vão para onde de dentro dos arquivos de log. Sem saber o que é onde eu não poderia dizer o porquê. Dito isso, o número de conexões aqui não parece irracional.