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 |
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 predicadoquery_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
equery_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 predicadomax_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
emax_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.
-
A tabela STV_QUERY_METRICS exibe as métricas de consultas em execução no momento.
-
A tabela STL_QUERY_METRICS registra as métricas de consultas concluídas.
-
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.