As operações de gravação estão sendo executadas em série na instância de núcleo único. Operações de leitura têm concordância. Isto é o que eu entendi das minhas leituras até agora.
Como afirmado na descrição do mecanismo de armazenamento WiredTiger, ele oferece uma capacidade de melhor concorrência devido ao bloqueio no nível do documento. De este post :
WiredTiger scales on modern, multi-CPU architectures. Using a variety of programming techniques such as hazard pointers, lock-free algorithms, fast latching and message passing, WiredTiger performs more work per CPU core than alternative engines.
Por algum motivo, meu caso de uso não parece se beneficiar disso. Eu tenho um banco de dados com muitas gravações simultâneas (principalmente atualizações), e esse tipo de carga não consegue superar o limite de 2000 atualizações por segundo. Aqui está a mongostat 10 output:
insert query update delete getmore command % dirty % used flushes vsize res qr|qw ar|aw netIn netOut conn time
3 780 1936 141 42 3|0 0.3 1.0 0 717.0M 289.0M 0|0 1|0 433k 6m 141 17:16:32
O rendimento do disco não está saturado, iostat -x 10 output:
avg-cpu: %user %nice %system %iowait %steal %idle
20.56 0.00 20.31 0.10 0.10 58.93
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
xvda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
xvdb 0.00 5.80 0.00 102.50 0.00 6188.80 60.38 3.46 33.79 0.46 4.72
Dado tudo isso, presumo que o gargalo está no uso da CPU, que é sempre estável em 100% o tempo todo para mongod process no top (do total de 200%, o que significa que apenas uma CPU de dois é usada). 58% de tempo ocioso de iostat também confirma isso.
Existem métodos para determinar se o armazenamento do WiredTiger está usando o bloqueio em nível de documento e dois núcleos de CPU simultaneamente, como deveria ser? Ou isso poderia acontecer devido a qualquer outro motivo que não o limite de capacidade da CPU?
As operações de gravação estão sendo executadas em série na instância de núcleo único. Operações de leitura têm concordância. Isto é o que eu entendi das minhas leituras até agora.
Que tipo de configuração do cliente mongodb você tem e que tipo de hardware?
Na minha experiência de benchmarking de diferentes mecanismos de armazenamento mongodb em sistemas diferentes, uma única instância do mongodb pode atingir uma parede rapidamente em operações por segundo.
Pode ser devido a vários motivos, como um gargalo de largura de banda ou tempo de envio. Para descobrir se é hora de envio, você pode tentar executar duas instâncias de mongod lado a lado. Se ambos atingirem 2000 atualizações por segundo e usarem 1 CPU cada, é possível que o tempo que leva para o mongod despachar comandos de atualização seja maior que o tempo que o sistema leva para executar alguns dos comandos de atualização. Portanto, não haveria razão para o mongod usar o outro núcleo da cpu porque o primeiro está sempre pronto para a próxima atualização (mesmo que esteja no limite).
Se você ainda tiver 2000 atualizações / segundo no total e ainda usar apenas um núcleo entre elas, será um problema diferente, e eu precisaria ver mais informações sobre a configuração do seu sistema para adivinhar o que é.
Se você quiser usar top , se mongoDB é o principal processador, você deve usar a opção 1 (pressione 1 após top iniciar) ou use um método alternativo conforme descrito aqui: Como medir o uso do núcleo da CPU separado para uma processo?
Para ferramentas mongo, isso depende da versão (as ferramentas mudaram de 2.x para 3.x, portanto, como usar ferramentas para exibir informações de bloqueio dependerá da sua versão), mas db.serverStatus() deve fornecer as informações que você ' está procurando. Veja Como vejo o status de bloqueios em minhas instâncias mongod? para obter informações mais detalhadas e específicas da versão. Lembre-se de verificar se a versão do MongoDB que você está usando corresponde à parte superior esquerda da página (clique no número da versão para alterar a versão da documentação que você está vendo).
Tags mongodb