Regras de monitoramento de consulta do WLM - Amazon Redshift
Definir uma regra do monitor de consultaMétricas de monitoramento de consultas para o Amazon Redshift provisionadoMétricas de monitoramento de consultas para o Amazon Redshift ServerlessModelos de regras de monitoramento de consultaTabelas de sistema e visualizações para regras de monitoramento de consultas

Regras de monitoramento de consulta do WLM

No gerenciador de workload (WLM) do Amazon Redshift, as regras de monitoramento de consulta definem limites de performance baseados em métricas para filas WLM e especificam qual ação tomar quando uma consulta ultrapassa esses limites. Por exemplo, para uma fila dedicada a consultas rápidas, convém criar uma regra que cancele consultas executadas por mais de 60 segundos. Para acompanhar consultas mal projetadas, convém ter outra regra que registre consultas que contenham loops aninhados.

Você define regras de monitoramento de consultas como parte da configuração do Workload Management (WLM – Gerenciamento do workload). É possível definir até 25 regras para cada fila, com um limite de 25 regras para todas as filas. Cada regra inclui até três condições, ou predicados, e uma ação. Um predicado consiste em uma métrica, uma condição de comparação (=, < ou > ) e um valor. Se todos os predicados para qualquer regra forem atendidos, a ação dessa regra será disparada. As ações de regra possíveis são registrar em log, saltar e anular, conforme abordado a seguir.

As regras em uma determinada fila se aplicam somente a consultas em execução nessa fila. A regra independe de outras regras.

O WLM avalia métricas a cada 10 segundos. Se mais de uma regra for disparada durante o mesmo período, o WLM iniciará a ação mais severa: abortar, saltar e registrar. Se a ação for saltar ou anular, a ação será registrada, e a consulta será removida da fila. Se a ação for registrar em log, a consulta continuará sendo executada na fila. O WLM inicia somente uma ação de registrar em log por consulta por regra. Se a fila contiver outras regras, essas regras permanecerão em vigor. Se a ação for saltar e a consulta for roteada para outra fila, as regras para a nova fila se aplicarão. Para obter mais informações sobre ações de monitoramento e rastreamento realizadas em consultas específicas, consulte o conjunto de exemplos em Trabalhar com a aceleração de consulta breve.

Quando todos os predicados de uma regra são atendidos, o WLM grava uma linha na tabela do sistema STL_WLM_RULE_ACTION. Além disso, o Amazon Redshift registra métricas de consulta para consultas em execução no momento em STV_QUERY_METRICS. As métricas para consultas concluídas são armazenadas em STL_QUERY_METRICS.

Definir uma regra de monitoramento de consultas

Você cria regras de monitoramento de consulta como parte da configuração do WLM, estabelecida como parte da definição do grupo de parâmetro do cluster.

Você pode criar regras usando o AWS Management Console ou programaticamente usando JSON.

nota

Se você optar por criar regras programaticamente, será altamente recomendável usar o console para gerar o JSON incluído por você na definição do parameter group. Para obter mais informações, consulte Criar ou modificar uma regra de monitoramento de consultas usando o console e Configurar valores de parâmetros usando a AWS CLI no Guia de gerenciamento do Amazon Redshift.

Para definir uma regra de monitoramento da consulta, você especifica os seguintes elementos:

  • Um nome de regra – Os nomes de regra devem ser exclusivos na configuração do WLM. Os nomes de regra podem ter até 32 caracteres alfanuméricos ou sublinhados e não podem conter espaços ou aspas. Pode haver até 25 regras por fila e o limite total para todas as filas é de 25 regras.

  • Um ou mais predicados – Você pode ter até três predicados por regra. Se todos os predicados para qualquer regra forem atendidos, a ação associada será disparada. Um predicado é definido por um nome de métrica, um operador ( =, < ou > ) e um valor. Um exemplo é query_cpu_time > 100000. Para obter uma lista de métricas e exemplos de valores para métricas diferentes, consulte Métricas de monitoramento de consultas para o Amazon Redshift provisionado posteriormente nesta seção.

  • Uma ação – Se mais de uma regra for acionada, o WLM escolherá a regra com a ação mais severa. As ações possíveis, em ordem crescente de gravidade, são:

    • Log – Registra informações sobre a consulta na tabela de sistema STL_WLM_RULE_ACTION. Use a ação de registrar em log quando você quiser gravar somente um registro de log. O WLM cria no máximo um log por consulta, por regra. Depois de uma ação de registrar em log, outras regras permanecerão em vigor e o WLM continuará monitorando a consulta.

    • Saltar (disponível apenas com WLM manual) – Registra a ação e salta a consulta para a próxima fila correspondente. Se não houver outra fila correspondente, a consulta será cancelada. O QMR salta somente instruções CREATE TABLE AS (CTAS) e consultas somente leitura, como instruções SELECT. Para ter mais informações, consulte Salto na fila de consultas do WLM.

    • Abort (Anular): registra a ação e encerra a consulta. A QMR não interrompe as instruções COPY e as operações de manutenção, como ANALYZE e VACUUM.

    • Alterar prioridade (disponível apenas com WLM automático) – Altera a prioridade de uma consulta.

Para limitar o tempo de execução de consultas, recomendamos a criação de uma regra de monitoramento de consulta em vez de usar o tempo limite do WLM. Por exemplo, é possível definir max_execution_time como 50.000 milissegundos, conforme mostrado no trecho de JSON a seguir.

"max_execution_time": 50000

No entanto, recomendamos que você defina uma regra de monitoramento de consulta equivalente que define query_execution_time como 50 segundos, conforme mostrado no trecho JSON a seguir.

"rules": 
[
    {
        "rule_name": "rule_query_execution",
        "predicate": [
            {
                "metric_name": "query_execution_time",
                "operator": ">",
                "value": 50
            }
        ],
        "action": "abort"
    }            
]

Para ver as etapas de como criar ou modificar uma regra de monitoramento de consultas, consulte Criar ou modificar uma regra de monitoramento de consultas usando o console e Propriedades do parâmetro wlm_json_configuration no Guia de gerenciamento do Amazon Redshift.

Você pode encontrar mais informações sobre regras de monitoramento de consulta nos seguintes tópicos:

Métricas de monitoramento de consultas para o Amazon Redshift provisionado

A tabela a seguir descreve as métricas usadas em regras de monitoramento de consulta. (Essas métricas são diferentes das métricas armazenadas nas tabelas de sistema STV_QUERY_METRICS e STL_QUERY_METRICS.)

Para uma determinada métrica, o limite de performance é acompanhado no nível de consulta ou no nível de segmento. Para obter mais informações sobre segmentos e etapas, consulte Planejamento de consulta e fluxo de trabalho de execução.

nota

O parâmetro Tempo limite do WLM é diferente das regras de monitoramento de consulta.

Métrica Nome Descrição
Tempo de CPU da consulta query_cpu_time O tempo de CPU usado pela consulta (em segundos). CPU time é diferente de Query execution time.

Os valores válidos são 0–999.999.

Leitura de blocos query_blocks_read O número de blocos de dados de 1 MB lidos pela consulta.

Os valores válidos são 0–1.048.575.

Contagem de linhas da verificação scan_row_count

O número de linhas em uma etapa de varredura. A contagem de linhas é o número total de linhas emitidas antes da filtragem das linhas marcadas para exclusão (linhas fantasmas) e antes da aplicação dos filtros de consulta definidos pelo usuário.

Os valores válidos são 0–999.999.999.999.999.

Tempo de execução da consulta query_execution_time O tempo de execução decorrido para uma consulta (em segundos). O tempo de execução não inclui o tempo gasto esperando em uma fila.

Os valores válidos são 0–86.399.
Tempo de fila de consulta query_queue_time Tempo gasto esperando em uma fila, em segundos.

Os valores válidos são 0–86.399.

Uso da CPU query_cpu_usage_percent A porcentagem da capacidade de CPU usada pela consulta.

Os valores válidos são 0–6.399.

Da memória para o disco query_temp_blocks_to_disk O espaço em disco temporário usado para gravar resultados intermediários, em blocos de 1 MB.

Os valores válidos são 0–319.815.679.

Distorção da CPU cpu_skew A taxa de utilização máxima da CPU para uma fatia em relação à média de utilização da CPU para todas as fatias. Essa métrica é definida no nível do segmento.

Os valores válidos são 0–99.

Distorção de E/S io_skew A taxa máxima de leitura de blocos (E/S) para uma fatia em relação à média de leitura de blocos para todas as fatias. Essa métrica é definida no nível do segmento.

Os valores válidos são 0–99.

Linhas unidas join_row_count O número de linhas processadas em uma etapa de junção.

Os valores válidos são 0–999.999.999.999.999.

Contagem de linhas unidas do loop aninhado nested_loop_join_row_count O número de linhas em uma união de loop aninhado.

Os valores válidos são 0–999.999.999.999.999.

Contagem de linhas de retorno return_row_count O número de linhas retornado pela consulta.

Os valores válidos são 0–999.999.999.999.999.

Tempo de execução do segmento segment_execution_time O tempo de execução decorrido para um único segmento, em segundos. Para evitar ou reduzir erros de amostragem, inclua segment_execution_time > 10 nas regras.

Os valores válidos são 0–86.388.
Contagem de linhas de verificação do Spectrum spectrum_scan_row_count O número de linhas de dados no Amazon S3 verificados por uma consulta do Amazon Redshift Spectrum.

Os valores válidos são 0–999.999.999.999.999.

Tamanho de verificação do Spectrum spectrum_scan_size_mb O tamanho dos dados no Amazon S3, em MB, verificados por uma consulta do Amazon Redshift Spectrum.

Os valores válidos são 0–999.999.999.999.999.

Prioridade da consulta query_priority A prioridade da consulta.

Os valores válidos são HIGHEST, HIGH, NORMAL, LOW e LOWEST. Ao comparar query_priority usando operadores maior que (>) e menor que (<), HIGHEST será maior que HIGH, HIGH será maior que NORMAL e assim por diante.

nota

  • Não há suporte para a ação de salto com o predicado query_queue_time. Ou seja, as regras definidas para saltar quando um predicado query_queue_time é atendido são ignoradas.

  • Os tempos de execução de segmento curto podem resultar em erros de amostragem com algumas métricas, como io_skew e query_cpu_usage_percent. Para evitar ou reduzir erros de amostragem, inclua o tempo de execução do segmento nas regras. Um bom ponto de partida é segment_execution_time > 10.

A exibição SVL_QUERY_METRICS mostra as métricas de consultas concluídas. A exibição SVL_QUERY_METRICS_SUMMARY mostra os valores máximos de métricas de consultas concluídas. Use os valores nessas exibições como um auxílio para determinar os valores limite para definir regras de monitoramento de consultas.

Métricas de monitoramento de consultas para o Amazon Redshift Serverless

A tabela a seguir descreve as métricas usadas em regras de monitoramento de consulta para o Amazon Redshift Serverless.

Métrica Nome Descrição
Tempo de CPU da consulta max_query_cpu_time O tempo de CPU usado pela consulta (em segundos). CPU time é diferente de Query execution time.

Os valores válidos são 0–999.999.

Leitura de blocos max_query_blocks_read O número de blocos de dados de 1 MB lidos pela consulta.

Os valores válidos são 0–1.048.575.

Contagem de linhas da verificação max_scan_row_count

O número de linhas em uma etapa de varredura. A contagem de linhas é o número total de linhas emitidas antes da filtragem das linhas marcadas para exclusão (linhas fantasmas) e antes da aplicação dos filtros de consulta definidos pelo usuário.

Os valores válidos são 0–999.999.999.999.999.

Tempo de execução da consulta max_query_execution_time

O tempo de execução decorrido para uma consulta (em segundos). O tempo de execução não inclui o tempo gasto esperando em uma fila. Se uma consulta exceder o tempo de execução definido, o Amazon Redshift Serverless interromperá a consulta.

Os valores válidos são 0–86.399.

Tempo de fila de consulta max_query_queue_time Tempo gasto esperando em uma fila, em segundos.

Os valores válidos são 0–86.399.

Uso da CPU max_query_cpu_usage_percent A porcentagem da capacidade de CPU usada pela consulta.

Os valores válidos são 0–6.399.

Da memória para o disco max_query_temp_blocks_to_disk O espaço em disco temporário usado para gravar resultados intermediários, em blocos de 1 MB.

Os valores válidos são 0–319.815.679.

Linhas unidas max_join_row_count O número de linhas processadas em uma etapa de junção.

Os valores válidos são 0–999.999.999.999.999.

Contagem de linhas unidas do loop aninhado max_nested_loop_join_row_count O número de linhas em uma união de loop aninhado.

Os valores válidos são 0–999.999.999.999.999.

nota

  • Não há suporte para a ação de salto com o predicado max_query_queue_time. Ou seja, as regras definidas para saltar quando um predicado max_query_queue_time é atendido são ignoradas.

  • Os tempos de execução de segmento curto podem resultar em erros de amostragem com algumas métricas, como max_io_skew e max_query_cpu_usage_percent.

Modelos de regras de monitoramento de consulta

Ao adicionar uma regra usando o console do Amazon Redshift, você pode optar por criar uma regra com base em um modelo predefinido. O Amazon Redshift cria uma nova regra com um conjunto de predicados e preenche os predicados com valores padrão. A ação padrão é registrar em log. Você pode modificar os predicados e a ação para atender ao caso de uso.

A tabela a seguir lista os modelos disponíveis.

Nome do modelo Predicados Descrição
Junção de loop aninhado nested_loop_join_row_count > 100 Uma união de loop aninhado pode indicar um predicado de união incompleto, o que normalmente resulta em um conjunto de retorno muito grande (um produto cartesiano). Use uma contagem de linhas baixa para encontrar uma consulta potencialmente perdida com antecedência.
Consulta retorna um número elevado de itens return_row_count > 1000000 Se dedicar uma fila a consultas simples, rápidas, você poderá incluir uma regra que encontra consultas que retornam uma contagem de linhas elevada. O modelo usa um padrão de 1 milhão de linhas. Para alguns sistemas, convém levar em consideração um milhão de linhas um número elevado ou, em um sistema maior, um bilhão ou mais de linhas pode ser alto.
União com um número elevado de itens join_row_count > 1000000000 Uma etapa de união que envolve um número excepcionalmente elevado de linhas pode indicar uma necessidade de filtros mais restritivos. O modelo usa um padrão de 1 bilhão de linhas. Para uma fila ad hoc (única) destinada a consultas rápidas e simples, você pode usar um número menor.
Uso elevado do disco durante a gravação de resultados intermediários query_temp_blocks_to_disk > 100000 Ao executar consultas usando mais do que a RAM do sistema disponível, o mecanismo de execução de consulta grava resultados intermediários no disco (memória derramada). Normalmente, essa condição é o resultado de uma consulta fictícia, que normalmente também é a consulta que usa o maior espaço em disco. O limite aceitável para uso do disco varia com base no tipo de nó do cluster e no número de nós. O modelo usa um padrão de 100.000 blocos, ou 100 GB. Para um cluster pequeno, convém usar um número menor.
Consulta demorada com distorção de E/S elevada segment_execution_time > 120 e io_skew > 1.30 A distorção de E/S ocorre quando uma fatia de nó apresenta uma taxa de E/S muito mais alta do que as outras fatias. Como ponto de partida, uma distorção de 1,30 (1,3 vez a média) é considerada alta. A distorção de E/S elevada nem sempre é um problema, mas quando combinada com um tempo de consulta demorado, pode indicar um problema no estilo de distribuição ou na chave de classificação.

Tabelas de sistema e visualizações para regras de monitoramento de consultas

Quando todos os predicados de uma regra são atendidos, o WLM grava uma linha na tabela do sistema STL_WLM_RULE_ACTION. Essa linha contém detalhes sobre a consulta que acionou a regra a ação resultante.

Além disso, o Amazon Redshift registra as métricas de consulta nas tabelas e visualizações do sistema a seguir.