Share via

Política de limites de pedidos

  • Artigo

A política de limites de pedidos de um grupo de cargas de trabalho permite limitar os recursos utilizados pelo pedido durante a respetiva execução.

O objeto de política

Cada limite consiste em:

  • Um tipo Value - o valor do limite.
  • IsRelaxable - um valor booleano que define se o limite pode ser reduzido pelo autor da chamada, como parte das propriedades do pedido.

Os seguintes limites são configuráveis:

Propriedade Tipo Description Valores suportados Propriedade de pedido de cliente correspondente
DataScope string O âmbito de dados da consulta. Este valor determina se a consulta se aplica a todos os dados ou apenas à cache frequente. All, HotCacheou null query_datascope
MaxMemoryPerQueryPerNode long A quantidade máxima de memória (em bytes) que uma consulta pode alocar. [1, 50% da RAM total de um único nó] max_memory_consumption_per_query_per_node
MaxMemoryPerIterator long A quantidade máxima de memória (em bytes) que um operador de consulta pode alocar. [1, 50% da RAM total de um único nó] maxmemoryconsumptionperiterator
MaxFanoutThreadsPercentage int A percentagem de threads em cada nó para mostrar a execução da consulta. Quando definido como 100%, o cluster atribui todas as CPUs em cada nó. Por exemplo, 16 CPUs num cluster implementado nos nós de D14_v2 do Azure. [1, 100] query_fanout_threads_percent
MaxFanoutNodesPercentage int A percentagem de nós no cluster para ativar a execução de consultas. Funções de forma semelhante a MaxFanoutThreadsPercentage. [1, 100] query_fanout_nodes_percent
MaxResultRecords long O número máximo de registos que um pedido pode devolver ao autor da chamada, acima do qual os resultados são truncados. O limite de truncamento afeta o resultado final da consulta, conforme devolvido ao cliente. No entanto, o limite de truncagem não se aplica a resultados intermédios de subconjuntas, como as que resultam de referências entre clusters. [1, 9223372036854775807] truncationmaxrecords
MaxResultBytes long O tamanho máximo de dados (em bytes) que um pedido pode devolver ao autor da chamada, acima do qual os resultados são truncados. O limite de truncamento afeta o resultado final da consulta, conforme devolvido ao cliente. No entanto, o limite de truncagem não se aplica a resultados intermédios de subconjuntas, como as que resultam de referências entre clusters. [1, 9223372036854775807] truncationmaxsize
MaxExecutionTime timespan A duração máxima de um pedido.
Notas:
1) Isto pode ser utilizado para colocar mais limites sobre os limites predefinidos no tempo de execução, mas não expandi-los.
2) O processamento de tempo limite não está na resolução de segundos, mas sim para impedir que uma consulta seja executada durante minutos.
3) O tempo necessário para ler o payload no cliente não é tratado como parte do tempo limite. Depende da rapidez com que o autor da chamada obtém os dados do fluxo.
4) O tempo total de execução pode exceder o valor configurado se a execução abortada demorar mais tempo a ser concluída.		 [00:00:00, 01:00:00] servertimeout

Nota

Um limite que não está definido ou definido como null, é retirado da política de limites de pedidos do grupo de default cargas de trabalho.

Utilização de recursos da CPU

As consultas podem utilizar todos os recursos da CPU no cluster. Por predefinição, quando várias consultas estão em execução em simultâneo, o sistema utiliza uma abordagem round robin justa para distribuir recursos. Esta estratégia é ideal para alcançar um elevado desempenho com consultas ad-hoc.

No entanto, existem cenários em que poderá querer restringir os recursos da CPU alocados a uma consulta específica. Por exemplo, se estiver a executar uma tarefa em segundo plano que possa acomodar latências mais elevadas. A política de limites de pedidos fornece a flexibilidade para especificar uma percentagem mais baixa de threads ou nós a utilizar ao executar operações de subconserção distribuídas. A predefinição é 100%.

O default grupo de cargas de trabalho

O default grupo de cargas de trabalho tem a seguinte política definida por predefinição. Esta política pode ser alterada.

{
  "DataScope": {
    "IsRelaxable": true,
    "Value": "All"
  },
  "MaxMemoryPerQueryPerNode": {
    "IsRelaxable": true,
    "Value": < 50% of a single node's total RAM >
  },
  "MaxMemoryPerIterator": {
    "IsRelaxable": true,
    "Value": 5368709120
  },
  "MaxFanoutThreadsPercentage": {
    "IsRelaxable": true,
    "Value": 100
  },
  "MaxFanoutNodesPercentage": {
    "IsRelaxable": true,
    "Value": 100
  },
  "MaxResultRecords": {
    "IsRelaxable": true,
    "Value": 500000
  },
  "MaxResultBytes": {
    "IsRelaxable": true,
    "Value": 67108864
  },
  "MaxExecutiontime": {
    "IsRelaxable": true,
    "Value": "00:04:00"
  }
}

Nota

  • Os limites no default grupo de cargas de trabalho têm de ser definidos e ter um valor diferentenull .
  • Todos os limites no default grupo de cargas de trabalho foram definidos IsRelaxable como true.
  • Os limites de pedidos são desativados para tipos de comandos específicos no default grupo de cargas de trabalho, tais como .export comandos e ingestão de comandos de consulta como .set-or-append e .set-or-replace. Quando estes comandos são atribuídos a um grupo de cargas de trabalho não predefinidos, os limites de pedidos especificados na política tornam-se aplicáveis.

Exemplo

O JSON seguinte representa um objeto de política de limites de pedidos personalizado:

{
  "DataScope": {
    "IsRelaxable": true,
    "Value": "HotCache"
  },
  "MaxMemoryPerQueryPerNode": {
    "IsRelaxable": true,
    "Value": 2684354560
  },
  "MaxMemoryPerIterator": {
    "IsRelaxable": true,
    "Value": 2684354560
  },
  "MaxFanoutThreadsPercentage": {
    "IsRelaxable": true,
    "Value": 50
  },
  "MaxFanoutNodesPercentage": {
    "IsRelaxable": true,
    "Value": 50
  },
  "MaxResultRecords": {
    "IsRelaxable": true,
    "Value": 1000
  },
  "MaxResultBytes": {
    "IsRelaxable": true,
    "Value": 33554432
  },
  "MaxExecutiontime": {
    "IsRelaxable": true,
    "Value": "00:01:00"
  }
}

Conteúdo relacionado