Query priority - Amazon Redshift

Si nous fournissons une traduction de la version anglaise du guide, la version anglaise du guide aura préséance en cas de contradiction. La traduction sera une traduction automatique.

Query priority

Toutes les requêtes n'ont pas la même importance, et souvent les performances d'une charge de travail ou d'un ensemble d'utilisateurs peuvent être plus importantes. Si vous avez activé la gestion automatique de la charge de travail, vous pouvez définir l'importance relative des requêtes dans une charge de travail en définissant une valeur de priorité. La priorité est spécifiée pour une file d'attente et héritée par toutes les requêtes associées à la file d'attente. Vous associez des requêtes à une file d'attente en mappant des groupes d'utilisateurs et des groupes de requêtes sur la file d'attente. Vous pouvez définir les priorités suivantes (de la plus élevée à la plus faible) :

  1. HIGHEST

  2. HIGH

  3. NORMAL

  4. LOW

  5. LOWEST

Les administrateurs utilisent ces priorités pour montrer l'importance relative de leurs charges de travail lorsque des requêtes aux priorités différentes sont liées aux mêmes ressources. Amazon Redshift utilise la priorité lorsqu'il laisse des requêtes dans le système, et pour déterminer la quantité de ressources allouées à une requête. Par défaut, les requêtes s'exécutent avec leur priorité définie sur NORMAL.

Une priorité supplémentaire, CRITICAL, qui est une priorité plus élevée que HIGHEST, est disponible pour les super-utilisateurs. Pour définir cette priorité, vous pouvez utiliser les fonctions CHANGE_QUERY_PRIORITY, CHANGE_SESSION_PRIORITY. et CHANGE_USER_PRIORITY. Pour autoriser un utilisateur de base de données à utiliser ces fonctions, vous pouvez créer une procédure stockée et accorder l'autorisation à un utilisateur. Pour obtenir un exemple, veuillez consulter CHANGE_SESSION_PRIORITY.

Note

Seule une requête CRITICAL peut être exécutée à la fois.

Prenons un exemple dans lequel la priorité d'une charge de travail d'extraction, de transformation et de chargement (ETL) est supérieure à la priorité de la charge de travail d'analyse. La charge de travail ETL s'exécute toutes les 6 heures, et la charge de travail d'analyse s'exécute tout au long de la journée. Lorsque seule la charge de travail d'analyse s'exécute sur le cluster, les priorités de requête permettent au système de générer un haut débit avec une utilisation optimale du système. Toutefois, lorsque la charge de travail ETL démarre, elle est prioritaire en raison de sa priorité élevée. En plus de bénéficier d'une allocation préférentielle des ressources après avoir été admises, les requêtes s'exécutant dans le cadre de la charge de travail ETL sont prioritaires pendant l'admission. Ainsi, la charge de travail ETL s'exécute de manière prévisible quelles que soient les autres exécutions sur le système. Cela fournit donc des performances prévisibles et la capacité pour les administrateurs à fournir des accords de niveau de service (SLA) à leurs utilisateurs métiers.

Au sein d'un cluster donné, les performances prévisibles d'une charge de travail à priorité élevée s'effectuent au prix de charges de travail à priorité plus faible Les charges de travail à priorité plus faible s'exécutent plus longtemps, car leurs requêtes attendent que des requêtes plus importantes se terminent. Ou, elles s'exécutent plus longtemps car elles récupèrent moins de ressources lorsqu'elles s'exécutent simultanément avec des requêtes à priorité plus élevée. Les requêtes à priorité plus faible ne connaissent pas de pénurie, mais poursuivent leur progression à un rythme inférieur.

Dans l'exempleprécédent, l'administrateur peut activer mise à l'échelle de la simultanéité pour la charge de travail d'analyse. Ainsi, cela permet à cette charge de travail de conserver sont débit, même si la charge de travail ETL s'exécute à une priorité élevée.

Configuring queue priority

Si vous avez activé la gestion automatique de la charge de travail, chaque file d'attente a une valeur de priorité. Les requêtes sont acheminées vers les files d'attente en fonction des groupes d'utilisateurs et des groupes de requêtes La priorité de file d’attente par défaut est NORMAL. Définissez la priorité supérieure ou inférieure en fonction de la charge de travail associée aux groupes d’utilisateurs et groupes de requêtes de la file d’attente.

Vous pouvez modifier la priorité d'une file d'attente sur la console Amazon Redshift. Sur la console Amazon Redshift, la page Workload Management (Gestion de la charge de travail) affiche les files d'attente et active la modification des propriétés de file d'attente, telles que Priority (Priorité). Pour définir la priorité à l'aide de l'interface de ligne de commande ou les opérations d'API, utilisez le paramètre wlm_json_configuration. Pour de plus amples informations, veuillez consulter Configuration de la gestion de la charge de travail dans le Amazon Redshift Cluster Management Guide.

L'exemple suivant wlm_json_configuration définit trois groupes d'utilisateurs (ingest, reporting et analytics). Les requêtes envoyées par les utilisateurs de l'un de ces groupes s'exécutent avec respectivement les priorités highest, normal et low.

[ { "user_group": [ "ingest" ], "priority": "highest", "queue_type": "auto" }, { "user_group": [ "reporting" ], "priority": "normal", "queue_type": "auto" }, { "user_group": [ "analytics" ], "priority": "low", "queue_type": "auto", "auto_wlm": true } ]

Changing query priority with query monitoring rules

Les règles de surveillance de requête (QMR) vous permettent de modifier la priorité d'une requête en fonction de son comportement pendant qu'elle s'exécute. Pour ce faire, spécifiez l'attribut de priorité dans une action et un prédicat QMR. Pour plus d'informations, consultez WLM query monitoring rules,

Par exemple, vous pouvez définir une règle pour interrompre n'importe quelle requête classée en tant que priorité high qui s'exécute pendant plus de 10 minutes.

"rules" :[ { "rule_name":"rule_abort", "predicate":[ { "metric_name":"query_cpu_time", "operator":">", "value":600 }, { "metric_name":"query_priority", "operator":"=", "value":"high" } ], "action":"abort" } ]

Un autre exemple consiste à spécifier une règle pour définir la priorité de requête sur lowest pour n'importe quelle priorité normal actuelle qui déverse plus de 1 To sur un disque.

"rules":[ { "rule_name":"rule_change_priority", "predicate":[ { "metric_name":"query_temp_blocks_to_disk", "operator":">", "value":1000000 }, { "metric_name":"query_priority", "operator":"=", "value":"normal" } ], "action":"change_query_priority", "value":"lowest" } ]

Monitoring query priority

Pour afficher la priorité pour les requêtes en attente et en cours d'exécution, consultez la colonne query_priority dans la table du système stv_wlm_query_state.

query | service_cl | wlm_start_time | state | queue_time | query_priority ---------+------------+----------------------------+------------------+------------+---------------- 2673299 | 102 | 2019-06-24 17:35:38.866356 | QueuedWaiting | 265116 | Highest 2673236 | 101 | 2019-06-24 17:35:33.313854 | Running | 0 | Highest 2673265 | 102 | 2019-06-24 17:35:33.523332 | Running | 0 | High 2673284 | 102 | 2019-06-24 17:35:38.477366 | Running | 0 | Highest 2673288 | 102 | 2019-06-24 17:35:38.621819 | Running | 0 | Highest 2673310 | 103 | 2019-06-24 17:35:39.068513 | QueuedWaiting | 62970 | High 2673303 | 102 | 2019-06-24 17:35:38.968921 | QueuedWaiting | 162560 | Normal 2673306 | 104 | 2019-06-24 17:35:39.002733 | QueuedWaiting | 128691 | Lowest

Pour répertorier les priorités de requête pour les requêtes terminées, consultez la colonne query_priority dans la table de système stl_wlm_query.

select query, service_class as svclass, service_class_start_time as starttime, query_priority from stl_wlm_query order by 3 desc limit 10;
query | svclass | starttime | query_priority ---------+---------+----------------------------+---------------------- 2723254 | 100 | 2019-06-24 18:14:50.780094 | Normal 2723251 | 102 | 2019-06-24 18:14:50.749961 | Highest 2723246 | 102 | 2019-06-24 18:14:50.725275 | Highest 2723244 | 103 | 2019-06-24 18:14:50.719241 | High 2723243 | 101 | 2019-06-24 18:14:50.699325 | Low 2723242 | 102 | 2019-06-24 18:14:50.692573 | Highest 2723239 | 101 | 2019-06-24 18:14:50.668535 | Low 2723237 | 102 | 2019-06-24 18:14:50.661918 | Highest 2723236 | 102 | 2019-06-24 18:14:50.643636 | Highest