diagnosticando mongodb comportamento falho e errático

Question

Temos uma instância do mongodb em execução em uma instância do amazon ec2 large (7.5GB) ubuntu (mesma máquina em que nosso servidor node.js está sendo executado). O tráfego aumentou muito recentemente e estamos começando a ver um comportamento errático do mongodb. O estado atual:

Observamos algumas consultas lentas usando o criador de perfil:

query   mydb.user 1327ms Wed Aug 01 2012 14:01:39
query:{ "_id" : ObjectId("500f45486562e7053d070363") } idhack responseLength:178 client:127.0.0.1 user: 

As entradas na tabela de usuários são pequenas, mas existem cerca de 50 milhões de entradas na tabela. Isso acontece a cada minuto ou dois e uma série de consultas lentas o seguem. Quando executamos as consultas lentas na linha de comando usando explain() , nada de ruim é relatado.

mongostat me diz:

insert  query update delete getmore command flushes mapped  vsize    res faults locked % idx miss %     qr|qw   ar|aw  netIn netOut  conn   set repl       time
138    804      9      0      96      36       0  60.2g   121g  3.42g      2      1.8          0       0|0     1|0    93k   479k    19 fgset    M   14:15:59
94    755      4      0      71      35       0  60.2g   121g  3.41g      0      1.5          0       0|0     1|0    78k   344k    19 fgset    M   14:16:00
93     17      4      0      75      27       0  60.2g   121g  3.41g      0      1.2          0       0|0     1|0    24k    31k    19 fgset    M   14:16:01
87     86      6      0      73      33       0  60.2g   121g  3.41g      0      0.9          0       0|0     1|0    31k   260k    19 fgset    M   14:16:02
101    531      3      0      62      19       0  60.2g   121g  3.41g      0        1          0       0|0     1|0    60k     1m    19 fgset    M   14:16:03
92    713      2      0      66      24       0  60.2g   121g  3.41g      1      0.9          0       0|0     0|0    72k     1m    17 fgset    M   14:16:04
163     91      6      0      93      46       0  60.2g   121g  3.41g      2      9.5          0       0|0     1|0    44k   256k    17 fgset    M   14:16:05
108     62      6      0      79      38       0  60.2g   121g  3.41g      4      1.2          0       0|0     1|0    32k   122k    17 fgset    M   14:16:06
137     23      6      0      81      32       0  60.2g   121g  3.41g      0      2.3          0       0|0     0|0    32k    67k    17 fgset    M   14:16:07

pidstat -r -p <pid> 5 me diz:

02:18:01 PM      1700    647.00      0.80 126778144 3578036  46.80  mongod
02:18:06 PM      1700   1092.00      1.20 126778144 3586364  46.91  mongod
02:18:11 PM      1700    689.60      0.20 126778144 3578912  46.81  mongod
02:18:16 PM      1700    740.80      1.20 126778144 3577652  46.79  mongod
02:18:21 PM      1700    618.60      0.20 126778144 3578100  46.80  mongod
02:18:26 PM      1700    246.00      1.00 126778144 3577392  46.79  mongod

Observe que nosso volume de banco de dados é um único volume ext4 e NÃO é um conjunto de ataques como recomendado .

Não sei qual é o próximo passo para entender o problema o suficiente para implementar uma correção. Qualquer entrada é apreciada.

    

Answer 1

Eu teria que dar uma olhada melhor na tendência ao longo do tempo para ter certeza aqui ( MMS ajudaria), mas você pode estar se deparando com um problema em que atingiu a memória residente máxima para o MongoDB nessa instância - as falhas de página não são tão altas, mas vejo uma pequena queda na memória residente. Se houver pressão de memória em outro lugar (de outro processo), você pode estar removendo páginas do MongoDB e / ou ter que paginar para o disco com mais freqüência do que deveria (uma página para o disco no EBS é bastante lenta).

Existem algumas coisas que você pode fazer para tornar o uso de RAM mais eficiente aqui:

1. Remova índices desnecessários - eles só ocupam RAM valiosa se usados - bons candidatos para remoção são índices únicos que são o elemento mais à esquerda de um índice composto em outro lugar. Isso realmente dependerá do seu uso e esquema aqui para o que pode ser removido, então tudo que eu posso dar são recomendações gerais.
2. Ajuste a leitura antecipada no volume do EBS down - isso é contra o que você lerá sobre o ajuste dos volumes do EBS em geral, mas o ajuste de leitura muito alto é um empecilho no uso de memória quando o perfil de acesso é aleatório ao contrário de seqüencial.

Para dar uma olhada nas configurações de leitura antecipada de um volume, execute este comando (requer privilégios root / sudo):

sudo blockdev --report

A saída listará algo assim:

RO    RA   SSZ   BSZ   StartSec            Size   Device
rw   256   512  4096          0     10737418240   /dev/xvda1

A coluna RA (em 256, que acredito ser o padrão na Amazon) é o que queremos ajustar aqui. Você faz isso executando algo assim:

blockdev --setra <value> <device name>

Para o exemplo acima, eu começaria cortando pela metade o valor:

blockdev --setra 128 /dev/xvda1

Eu entro em mais detalhes sobre o quão baixo você deve definir esse valor e o raciocínio por trás dele em esta resposta se você gostaria de saber mais. Observe que a alteração requer que uma reinicialização do processo mongod entre em vigor.

Depois de ter feito as duas coisas, você poderá extrair mais desempenho da RAM naquela instância do xlarge. Se não, ou se a pressão da memória vem de outro lugar e ser mais eficiente não é suficiente, então é hora de obter mais RAM.

Atualizando o armazenamento do EBS para um volume RAID como você mencionou ou usando o novo Instâncias de IOPS provisionadas e EBS otimizadas (ou os nós SSD Cluster Compute se você tiver dinheiro para queimar) ajudarão a parte" lenta "das operações (paginação do disco), mas nada supera os benefícios da memória operações - eles ainda são uma ordem de magnitude mais rápida, mesmo com as melhorias do subsistema de disco.