Entendendo IXSCAN e COLLSCAN em logs do MongoDB

Question

Estou tentando percorrer alguns logs do Mongo em uma tentativa de encontrar operações lentas que preciso otimizar. O log de consulta lenta está no padrão e está registrando operações acima de 100ms.

Acho que é seguro dizer que, em geral, uma pesquisa por COLLSCANS mostrará consultas que precisam de atenção. O que é menos claro é que se o IXSCANS é um detalhe que eu deveria procurar.

Considerando a documentação do MongoDB aqui:

link

meu entendimento é que esta é uma situação binária, uma consulta é um COLLSCAN ou um IXSCAN. Então, se eu for para o IXSCAN, eu estarei examinando TODAS as consultas lentas que não são COLLSCANS. Isso é verdade?

    

Answer 1

I'm attempting to grep through some Mongo logs in an attempt to find slow operations that I need to optimize. Slow query logging is at the default and is logging operations over 100ms.

Em vez de percorrer os registros do MongoDB, recomendo usar os scripts do mtools project de código-fonte aberto. OBSERVAÇÃO: não sou o autor original mtools , mas sou colaborador.

mtools é uma coleção de scripts em Python que foi inspirada pela dificuldade de usar GBs de logs para tentar localizar informações de interesse para implementações do MongoDB de produção. Os scripts principais são destinados a se adequarem ao fluxo de trabalho típico da linha de comando da saída da tubulação por meio de filtros sucessivos (por exemplo, mlogfilter --scan | mplotqueries ).

Por exemplo:

• mloginfo --queries é um bom ponto de partida: agrega padrões de consulta para que você possa se concentrar em consultas que executar com frequência e ter mais impacto geral na sua implantação.
• mlogfilter é essencialmente um grep para logs do MongoDB: você pode filtrar linhas de log por namespace, duração, conexão, padrão e outros critérios. A opção --scan é útil para identificar consultas ineficientes que não são necessariamente uma verificação de coleção.
• mplotqueries é uma ferramenta para visualizar registros, o que pode ser muito útil para identificar padrões e valores discrepantes.

I think that it's safe to say that generally speaking a search for COLLSCANS will show queries that need attention. What's less clear is that if IXSCANS is a detail I should search on.

As verificações de coleções geralmente são de interesse, mas também podem ser o resultado de consultas únicas ou uso esperado em uma pequena coleção. Em vez de focar no tipo de consulta, eu analisaria consultas lentas (ou operações lentas em geral) para que sua implantação entendesse melhor o que você poderia melhorar. Usar um índice geralmente é bom, mas há usos de índice ineficientes (por exemplo, classificação na memória ou expressões regulares insensíveis a maiúsculas e minúsculas ) que podem valer a pena ser endereçadas.

my understanding is that this is a binary situation, a query is either a COLLSCAN or an IXSCAN. So if I grep for IXSCAN, I will be looking at ALL the slow queries that are not COLLSCANS. Is this true?

Se você grep for IXSCAN , você encontrará todas as linhas de log que mencionam IXSCAN , mas o resultado do log de consultas lentas definitivamente não é binário e também irá variar de acordo com a versão do servidor MongoDB. Embora o uso eficiente de índices seja uma otimização óbvia, existem vários etapas do planejador de consulta que podem ser relevantes para entender o desempenho da consulta.

Quando você encontra uma consulta lenta interessante nos registros, a próxima etapa é geralmente analisar mais detalhadamente explain output . Eu uso o modo explain(true) (também conhecido como allPlansExecution ) Isso mostra detalhes para planos de consulta que foram considerados, bem como o plano vencedor. Se você não souber como interpretar a saída de explicação para uma consulta lenta, eu recomendaria postar em DBA StackExchange .

É importante notar que explicar uma consulta não é uma medida do desempenho real com uma carga de trabalho. Em operação normal, os planos de consulta são armazenados em cache, enquanto a saída explain detalhada reavalia especificamente os índices candidatos e o plano de consulta. Consulte os Planos de consulta no manual do MongoDB para obter mais informações.