Otimizar o desempenho do N1QL usando a criação de perfil de solicitação

O monitoramento revelou o consumo de recursos. E agora?

O Couchbase Server 4.5 introduziu um mecanismo para ficar de olho nas solicitações em execução, de modo que as solicitações com desempenho lento pudessem ser destacadas.

Este artigo da DZone aborda o assunto do monitoramento N1QL em grande detalhe, mas a questão agora é: temos os desordeiros, como verificamos suas demandas?

Em termos gerais, todo mecanismo de banco de dados fornece meios para analisar o plano de consulta usado por uma solicitação para retornar dados, na forma de algum tipo de instrução EXPLAIN, mas isso faz exatamente o que a palavra diz: explica o plano, mas não diz de fato qual parte do plano está se comportando mal, usando números concretos.

Administradores de banco de dados experientes podem dizer, usando uma mistura de, bem, experiência, heurística e intuição, como um plano específico poderia ser aprimorado, mas esse conjunto de habilidades específicas requer uma quantidade substancial de treinamento e, para ser justo, um certo grau de adivinhação também está envolvido.

Podemos fazer melhor?

Entrar na criação de perfil

O Couchbase 5.0 introduz, entre outras coisas, a capacidade de coletar métricas em todas as partes móveis de solicitações individuais.

Quando o recurso está ativado, as informações de criação de perfil são retornadas pela solicitação após o documento de resultados e ficam disponíveis nos espaços de chave do sistema para processamento posterior.

Essa métrica mostra a árvore de execução em detalhes, com informações como o tempo gasto em cada operador e em cada fase de processamento, bem como os documentos ingeridos e digeridos.

Munidos desse conjunto de dados, os administradores de banco de dados podem identificar facilmente os operadores caros em uma solicitação e resolver o problema, por exemplo, criando o índice correto para minimizar o número de chaves qualificadas retornadas pela varredura do índice.

Mas vamos começar do início.

Ativação da criação de perfil

O uso mais frequente da criação de perfis é para entender por que um determinado extrato é lento.

Dessa forma, a declaração lenta já foi identificada e provavelmente está sendo testada em um ambiente sandbox - a única informação necessária é o texto da declaração culpada e não há necessidade de coletar perfis de qualquer outra coisa.

Por outro lado, um nó de produção pode estar passando por um patch lento.

A solicitação culpada não foi identificada e é importante coletar todas as informações de diagnóstico disponíveis imediatamente para que, assim que a solicitação lenta for identificada, a criação de perfil já esteja disponível sem a necessidade de executar novamente a instrução ofensiva.

No nível da solicitação

Isso pode ser feito com o perfil parâmetro da API REST da solicitação, passado para o serviço de consulta junto com a instrução da solicitação - ideal para investigar instruções individuais.

Isso pode ser feito no nível mais baixo possível, como exemplificado a seguir enrolar exemplo

Ou, mais simplesmente, de uma sessão de cbq shell

O Query Workbench habilita a criação de perfil por padrão, como veremos mais adiante.

O perfil assume três valores: desligado (o padrão), fasese horários.

A primeira, como esperado, apenas desativa o recurso.

A segunda permite um resumo dos tempos de execução para cada fase da solicitação, enquanto a última oferece o nível mais alto de informações disponíveis: tempos completos por operador de execução.

Em nível de serviço

Quando a criação de perfil é necessária em todas as solicitações, ela pode ser ativada na inicialização do nó por meio do -Perfil parâmetro da linha de comando.

Ele usa os mesmos argumentos que o parâmetro da API REST de consulta, com o mesmo significado.

Qualquer solicitação que não especifique nenhum nível de criação de perfil no nível da API REST assume o valor do argumento da linha de comando como a opção selecionada.

Em tempo real

Quando os clusters de produção estão mostrando sinais de fadiga, é possível alterar a configuração do perfil de serviço de consulta em tempo real por meio do ponto de extremidade REST /admin/settings, por exemplo

Isso tem o mesmo efeito que inicializar o serviço de consulta usando o comando -Perfil no entanto, ele também se aplica a solicitações que já foram iniciadas, o que significa que, quando as solicitações não especificarem uma configuração de perfil de nível de consulta, o nível recém-definido será considerado a opção selecionada.

É importante saber que as informações de perfil são coletadas o tempo todo - as opções acima apenas determinam se e quantas informações são relatadas.

Portanto, é possível ativar retroativamente a criação de perfis para solicitações já iniciadas, o que significa que, ao perceber uma lentidão no sistema, um DBA pode criar perfis para todas as solicitações já em execução, sem precisar reenviar nenhuma das solicitações ou investigar primeiro qual delas está com desempenho ruim!

Obtenção de informações de perfil

As informações de perfil de solicitação individual são disponibilizadas como um subdocumento json que detalha a árvore de execução.

Em termos gerais, trata-se de uma estrutura com o mesmo formato e conteúdo muito próximo do EXPLICAR mas acrescido de estatísticas de execução.

Isso pode ser acessado pelo aplicativo cliente, por meio do documento de resposta (que é útil para investigações pontuais), e por terceiros, por meio dos espaços-chave do sistema, o que é útil, por exemplo, para comparar diferentes variações da mesma declaração ou a execução da mesma declaração com valores diferentes para espaços reservados.

Da resposta da solicitação

O exemplo a seguir mostra a execução de uma instrução no cbq, com a criação de perfil ativada

Observe que a resposta agora inclui um perfil seção, mostrando informações de fase, como phaseTimes, phaseCounts, phaseOperators (respectivamente, o tempo gasto na execução de cada fase, o número de documentos processados por fase e o número de operadores que executam cada fase) - as únicas informações fornecidas quando perfil é definido como fases - bem como um executionTimings subseção.

Dos espaços de chaves do sistema

As consultas nos espaços de chave do sistema podem retornar informações de criação de perfil de solicitação, desde que a criação de perfil esteja ativada para essas solicitações no momento da consulta.

Aqui está um exemplo rápido:

O registro da seleção em system:active_requests em si é uma informação de fase esportiva.

Se a criação de perfil estiver definida como horáriosA árvore de execução detalhada é relatada como plano acessível por meio do meta() função:

As informações mostradas aqui em system:active_requests também é acessível a partir de system:completed_requestssupondo que a solicitação em questão, ao ser concluída, esteja qualificada para armazenamento em system:completed_requests e a criação de perfil foi ativada.

Observe que as informações de tempo retornadas por system:active_requests é atualo que significa que ele inclui os tempos de execução acumulados até o momento: um segundo select em system:active_requests pode, portanto, ser usado para determinar o custo de um operador específico no intervalo de tempo decorrido entre as duas seleções.

Informações fornecidas

Conforme mostrado no exemplo a seguir

O documento da árvore de execução informa, para cada operador, o número de documentos ingeridos e digeridos (#itemsIn e #itemsOut), tempo gasto na execução do código do operador (execTime), aguardando agendamento (kernTime) e aguardando que os serviços forneçam dados (servTime), o número de vezes que o operador mudou de estado (executando, aguardando agendamento, aguardando dados) e o estado atual (supondo que a solicitação ainda não tenha sido concluída).

As estatísticas do operador são propositalmente muito detalhadas por natureza: cada medida individual é conhecida por se destacar durante investigações específicas de desempenho, e não tenho vergonha de dizer que elas também foram usadas de forma proveitosa durante minhas próprias sessões de depuração!

Para dar uma ideia do tipo de coisas que podem ser alcançadas, vamos considerar phaseSwitches.

Suponha que, depois de coletar perfis duas vezes, o número de phaseSwitches para uma determinada operadora não aumentou.

Esse operador específico pode não estar operando corretamente: o estado ficar preso em "serviços"dependendo do operador, ele pode estar esperando no armazenamento de documentos (para uma busca) ou no serviço de indexação (para uma varredura).

Talvez o serviço relevante esteja inativo ou travado?

Por outro lado, se estiver preso em "kernel"Se o operador não aceitar dados, é possível que um consumidor no pipeline não esteja aceitando dados ou que a máquina esteja tão carregada que o programador não esteja encontrando fatias de tempo para o operador.

A próxima seção abordará alguns sinais reveladores de alguns cenários comuns, primeiro os cenários mais prováveis.

Interpretação de perfis

Qualquer operador: tempo elevado do núcleo

Esse é um gargalo em um operador mais adiante no pipeline.

Procure um operador com alto tempo de execução ou de serviços.

Se não for possível encontrar um, o kernel do tempo de execução está lutando para agendar operadores: o nó de consulta está sobrecarregado e adicionar um novo pode ser útil.

Fetches, Joins, Scans: tempos de serviço elevados

Isso pode indicar um serviço externo estressado.

Uma confirmação disso viria de uma baixa taxa de mudança em #itemsOutEmbora isso exija a obtenção do mesmo perfil mais de uma vez, o que pode ser inconveniente (ou impossível, se a solicitação já tiver sido concluída).

Como alternativa, procure os sintomas descritos a seguir.

Fetches e Joins: alto tempo de serviço por documento recebido

As buscas de documentos individuais devem ser rápidas.

Dividir servTime por #itemsOut deve sempre gerar tempos de busca substancialmente menores que um milissegundo.

Se não for, o armazenamento de documentos está sob estresse.

Para deixar claro, não é necessariamente a solicitação com perfil que está colocando o armazenamento sob estresse: o mais provável é que o problema seja a carga geral do serviço.

Uma maneira de verificar se a carga geral é o problema, pelo menos durante a execução de testes de estresse, é reduzir o número de clientes de trabalho: em um armazenamento sobrecarregado, os tempos de busca individuais permanecem constantes à medida que o número de clientes diminui e só começam a melhorar quando a carga chega a um nível que pode ser mais facilmente manipulado.

Fetches: alto número de documentos ingeridos

Um bom plano de consulta deve usar um índice que produza apenas as chaves de documento relevantes para a solicitação.

Se o número de chaves passadas para o operador Fetch for muito maior do que o número final de documentos retornados ao cliente, o índice escolhido não é suficientemente seletivo.

Digitalizações: grande número de documentos produzidos

Essa é a contrapartida do sintoma anterior: o índice escolhido não é suficientemente seletivo. Considere a possibilidade de criar um índice para que predicados adicionais possam ser enviados para a varredura do índice.

Une: baixo número de documentos ingeridos, alto número de documentos produzidos

Mais uma vez, definitivamente um caminho de índice errado: a junção deveria produzir tantos resultados em primeiro lugar?

Filtros: alto número de documentos ingeridos, baixo número de documentos produzidos

Outro indicador de "índice escolhido definitivamente não é seletivo o suficiente".

Filtros: alto tempo de execução

Isso nunca deve acontecer e, se acontecer, é mais provável que seja acompanhado pelo sintoma anterior.

Além de o índice não ser seletivo o suficiente e retornar muitas chaves de documentos, a avaliação de todas as expressões na cláusula WHERE para tantos documentos está se mostrando bastante cara!

Projeção: alto tempo de execução

Novamente, um improvável: o serviço de consulta está lutando para reunir os documentos de resultados para a solicitação.

Quantos termos você tem na cláusula de projeção do comando SELECT? Corte alguns!

Você tem expressões complexas?

Stream: alto tempo de execução

A solicitação está se esforçando para converter o resultado em formato JSON e enviá-lo ao cliente.

O bonito O parâmetro REST pode ter sido definido como verdadeiro por engano.

A lista de projeções pode ter um número excessivo de termos.

Como alternativa, há um problema de rede ou os documentos de resultado que estão sendo enviados são grandes demais para a rede suportar.

Controles

Muitas vezes, o comportamento da solicitação depende de valores de espaço reservado, portanto, seria muito útil capturar valores de espaço reservado junto com os perfis.

Isso pode ser feito com o controles API REST de consulta, parâmetro de linha de comando e /admin/settings REST, que recebe um verdadeiro ou falso valor.

Seu comportamento é exatamente o mesmo que o do perfil e pode ser definido por solicitação, na inicialização, em tempo real, em todo o serviço, sendo também aplicado retrospectivamente a solicitações em execução que não tenham especificado uma configuração.

Os parâmetros nomeados e posicionais serão relatados na saída da solicitação em sua própria seção de controle:

bem como nos espaços de chaves do sistema (embora, diferentemente dos perfis, não seja necessário acessar nenhum anexo por meio do meta() função):

Perfis visuais

Uma maneira bastante fácil de acessar informações detalhadas de criação de perfil para declarações individuais, sem precisar fazer nada de especial, é por meio da guia Query (Consulta) na interface do usuário do Admin Console.

O Query WorkBench ativa a criação de perfis por padrão e, após a conclusão da solicitação, os tempos e as contagens de documentos ficam prontamente disponíveis em forma de gráfico, clicando no botão "plan".

As operadoras são codificadas por cores de acordo com o custo e, ao passar o mouse sobre cada operadora, aparecem várias informações sobre os horários brutos.

As Preferências permitem alterar as configurações de criação de perfil, bem como outras configurações, como parâmetros nomeados e posicionais.

A criação de perfis é muito mais do que apenas criar perfis

As informações de perfil e controles também podem ser usadas para um monitoramento mais detalhado.

Por exemplo, para localizar solicitações com qualquer operador que produza quantidades excessivas de documentos, pode-se usar

(altere o limite dos documentos de saída conforme necessário).

O exemplo é bastante simplista e, na verdade, poderia ser feito com mais facilidade usando phaseCounts, mas troque a cláusula ANY para satisfazer

e pronto!, as solicitações que carregam um espaço de chave específico são reveladas.

Da mesma forma, a localização de qualquer solicitação que tenha usado um valor específico para qualquer parâmetro nomeado pode ser obtida com

(substitua "algum parâmetro" e "valor-alvo" pelos valores necessários!)

As possibilidades são infinitas.

Uma última consideração

As informações de criação de perfil são mantidas na própria árvore de execução, que usa uma quantidade razoável de memória.

Isso, por si só, não é um problema, mas lembre-se de que quando uma solicitação de execução lenta se torna elegível para armazenamento em system:completed_requests e perfil é definido como horáriosa árvore de execução inteira também será armazenada.

Isso, novamente, não é um problema em si. No entanto, pode se tornar um problema se system:completed_requests é definido para registrar todas as solicitações, não tem limite, e todas as solicitações têm perfil definido como horáriosNesse caso, o uso da memória pode crescer além do razoável, porque você está armazenando todos os tempos de todas as solicitações já executadas desde o início dos tempos!

Felizmente, as configurações padrão para system:completed_requests O registro em log significa que você não terá problemas sem saber e, de qualquer forma, não estou sugerindo que você deva ser econômico com a quantidade de horas que registra, mas esse é um caso em que o excesso pode ser doloroso.

Você foi avisado.

Conclusões

A partir da versão 5.0 do Couchbase Server, o N1QL oferece ferramentas especializadas para analisar e analisar os tempos de execução com profundidade considerável.

Foram dados exemplos de como acessar a funcionalidade e interpretar os dados coletados.