Directiva de límites de solicitudes
Se aplica a: ✅Microsoft Fabric✅azure Data Explorer
La directiva de límites de solicitudes de un grupo de cargas de trabajo permite limitar los recursos utilizados por la solicitud durante su ejecución.
El objeto de directiva
Cada límite consta de:
- Un
Value
con tipo: el valor del límite. -
IsRelaxable
: un valor booleano que define si el autor de la llamada puede relajar el límite, como parte de las propiedades de solicitud de la solicitud.
Los límites siguientes son configurables:
Propiedad | Tipo | Descripción | Valores admitidos | Propiedad de solicitud de cliente coincidente |
---|---|---|---|---|
DataScope | string |
Ámbito de datos de la consulta. Este valor determina si la consulta se aplica a todos los datos o simplemente a la caché activa. |
All , HotCache o null |
query_datascope |
MaxMemoryPerQueryPerNode | long |
La cantidad máxima de memoria (en bytes) que puede asignar una consulta. | [1 , 50% deram total de un nodo ] |
max_memory_consumption_per_query_per_node |
MaxMemoryPerIterator | long |
Cantidad máxima de memoria (en bytes) que puede asignar un operador de consulta . | [1 , Min(32212254720 , 50% de ram total de un solo nodo)] |
maxmemoryconsumptionperiterator |
MaxFanoutThreadsPercentage | int |
Porcentaje de subprocesos de cada nodo al que se va a distribución ramificada la ejecución de consultas. Cuando se establece en 100%, el clúster asigna todas las CPU de cada nodo. Por ejemplo, 16 CPU en un clúster implementado en nodos de Azure D14_v2. | [1 , 100 ] |
query_fanout_threads_percent |
MaxFanoutNodesPercentage | int |
Porcentaje de nodos del clúster al que se va a distribución ramificada de la ejecución de consultas. Funciona de forma similar a MaxFanoutThreadsPercentage . |
[1 , 100 ] |
query_fanout_nodes_percent |
MaxResultRecords | long |
El número máximo de registros que puede devolver una solicitud al autor de la llamada, más allá del cual se truncan los resultados. El límite de truncamiento afecta al resultado final de la consulta, tal como se devuelve al cliente. Sin embargo, el límite de truncamiento no se aplica a los resultados intermedios de las subconsultas, como las que resultan de tener referencias entre clústeres. | [1 , 9223372036854775807 ] |
truncationmaxrecords |
MaxResultBytes | long |
El tamaño máximo de datos (en bytes) que una solicitud puede devolver al autor de la llamada, más allá del cual se truncan los resultados. El límite de truncamiento afecta al resultado final de la consulta, tal como se devuelve al cliente. Sin embargo, el límite de truncamiento no se aplica a los resultados intermedios de las subconsultas, como las que resultan de tener referencias entre clústeres. | [1 , 9223372036854775807 ] |
truncationmaxsize |
MaxExecutionTime | timespan |
Duración máxima de una solicitud. Notas de : 1) Esto se puede usar para colocar más límites sobre el límites predeterminados de en el tiempo de ejecución, pero no ampliarlos. 2) El procesamiento de tiempo de espera no está en la resolución de segundos, sino que está diseñado para evitar que una consulta se ejecute durante minutos. 3) El tiempo necesario para leer la carga en el cliente no se trata como parte del tiempo de espera. Depende de la rapidez con la que el autor de la llamada extrae los datos de la secuencia. 4) El tiempo total de ejecución puede superar el valor configurado si la anulación de la ejecución tarda más tiempo en completarse. |
[00:00:00 , 01:00:00 ] |
servertimeout |
Propiedad | Tipo | Descripción | Valores admitidos | Propiedad de solicitud de cliente coincidente |
---|---|---|---|---|
DataScope | string |
Ámbito de datos de la consulta. Este valor determina si la consulta se aplica a todos los datos o simplemente a la caché activa. |
All , HotCache o null |
query_datascope |
MaxMemoryPerQueryPerNode | long |
La cantidad máxima de memoria (en bytes) que puede asignar una consulta. | [1 , 50% deram total de un nodo ] |
max_memory_consumption_per_query_per_node |
MaxMemoryPerIterator | long |
Cantidad máxima de memoria (en bytes) que puede asignar un operador de consulta . | [1 , Min(32212254720 , 50% de ram total de un solo nodo)] |
maxmemoryconsumptionperiterator |
MaxFanoutThreadsPercentage | int |
Porcentaje de subprocesos de cada nodo al que se va a distribución ramificada la ejecución de consultas. Cuando se establece en 100%, eventhouse asigna todas las CPU de cada nodo. Por ejemplo, 16 CPU en un centro de eventos implementado en nodos de Azure D14_v2. | [1 , 100 ] |
query_fanout_threads_percent |
MaxFanoutNodesPercentage | int |
Porcentaje de nodos del centro de eventos al que se va a distribución ramificada la ejecución de consultas. Funciona de forma similar a MaxFanoutThreadsPercentage . |
[1 , 100 ] |
query_fanout_nodes_percent |
MaxResultRecords | long |
El número máximo de registros que puede devolver una solicitud al autor de la llamada, más allá del cual se truncan los resultados. El límite de truncamiento afecta al resultado final de la consulta, tal como se devuelve al cliente. Sin embargo, el límite de truncamiento no se aplica a los resultados intermedios de las subconsultas, como los resultados de tener referencias entre centros de eventos. | [1 , 9223372036854775807 ] |
truncationmaxrecords |
MaxResultBytes | long |
El tamaño máximo de datos (en bytes) que una solicitud puede devolver al autor de la llamada, más allá del cual se truncan los resultados. El límite de truncamiento afecta al resultado final de la consulta, tal como se devuelve al cliente. Sin embargo, el límite de truncamiento no se aplica a los resultados intermedios de las subconsultas, como los resultados de tener referencias entre centros de eventos. | [1 , 9223372036854775807 ] |
truncationmaxsize |
MaxExecutionTime | timespan |
Duración máxima de una solicitud. Notas de : 1) Esto se puede usar para colocar más límites sobre el límites predeterminados de en el tiempo de ejecución, pero no ampliarlos. 2) El procesamiento de tiempo de espera no está en la resolución de segundos, sino que está diseñado para evitar que una consulta se ejecute durante minutos. 3) El tiempo necesario para leer la carga en el cliente no se trata como parte del tiempo de espera. Depende de la rapidez con la que el autor de la llamada extrae los datos de la secuencia. 4) El tiempo total de ejecución puede superar el valor configurado si la anulación de la ejecución tarda más tiempo en completarse. |
[00:00:00 , 01:00:00 ] |
servertimeout |
Nota
Un límite que no está definido o que se define como null
, se toma de la directiva de límites de solicitudes del grupo de cargas de trabajo de default
.
Uso de recursos de CPU
Las consultas pueden usar todos los recursos de CPU del clúster. De forma predeterminada, cuando varias consultas se ejecutan simultáneamente, el sistema emplea un enfoque de round robin justo para distribuir recursos. Esta estrategia es óptima para lograr un alto rendimiento con consultas ad hoc.
Las consultas pueden usar todos los recursos de CPU en eventhouse. De forma predeterminada, cuando varias consultas se ejecutan simultáneamente, el sistema emplea un enfoque de round robin justo para distribuir recursos. Esta estrategia es óptima para lograr un alto rendimiento con consultas ad hoc.
Sin embargo, hay escenarios en los que es posible que quiera restringir los recursos de CPU asignados a una consulta específica. Por ejemplo, si ejecuta un trabajo en segundo plano que puede dar cabida a latencias más altas. La directiva de límites de solicitudes proporciona la flexibilidad de especificar un porcentaje menor de subprocesos o nodos que se usarán al ejecutar operaciones de subconsultas distribuidas. La configuración predeterminada es 100%.
El grupo de cargas de trabajo de default
El grupo de cargas de trabajo default
tiene la siguiente directiva definida de forma predeterminada. Esta directiva se puede modificar.
{
"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
- Los límites del grupo de cargas de trabajo de
default
deben definirse y tener un valor que no seanull
. - Todos los límites del grupo de cargas de trabajo de
default
tienenIsRelaxable
establecido entrue
. - Los límites de solicitudes están desactivados para tipos de comandos específicos dentro del grupo de cargas de trabajo de
default
, como comandos de.export
y ingesta de comandos de de consulta, como.set-or-append
y.set-or-replace
. Cuando estos comandos se asignan a un grupo de cargas de trabajo no predeterminados, los límites de solicitud especificados en la directiva se aplican.
Ejemplo
El siguiente JSON representa un objeto de directiva de límites de solicitudes personalizados:
{
"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"
}
}
Contenido relacionado
- grupos de cargas de trabajo de
- propiedades de solicitud de cliente
- workload_group .alter-merge
- .create-or-alter workload_group
- workload_group .drop
- comando .show workload_group