Modifying the WLM configuration - 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.

Modifying the WLM configuration

La solution la plus simple pour modifier la configuration WLM consiste à utiliser la console Amazon Redshift. Vous pouvez également utiliser l'AWS CLI ou l'API Amazon Redshift.

Lorsque vous basculez votre cluster de la gestion automatique de la charge de travail à la gestion manuelle de la charge de travail, ce dernier passe à l'état pending reboot. Cette modification prend seulement effet lors du prochain redémarrage d'un cluster.

Pour plus d’informations sur la modification des configurations WLM, voir Configuration de la gestion de la charge de travail dans le Amazon Redshift Cluster Management Guide.

Migrating from manual WLM to automatic WLM

Pour optimiser le débit du système et utiliser efficacement les ressources, nous vous recommandons de définir la gestion automatique de la charge de travail pour vos files d'attente. Utilisez l'approche suivante pour configurer une transition en douceur entre la gestion manuelle de la charge de travail et la gestion automatique de la charge de travail.

Pour passer de la gestion manuelle de la charge de travail à la gestion automatique de la charge de travail, tout en utilisant les priorités de requête, nous vous recommandons de créer un nouveau groupe de paramètres, puis d'attacher ce groupe de paramètres à votre cluster. Pour plus d'informations, consultez Groupes de paramètres Amazon Redshift dans le Amazon Redshift Cluster Management Guide..

Important

La modification du groupe de paramètres ou le passage de la gestion manuelle de la charge de travail à la gestion automatique de la charge de travail exige un redémarrage du cluster. Pour plus d'informations, consultez WLM dynamic and static configuration properties,

Prenons un exemple avec trois files d'attente de gestion manuelle de la charge de travail. Une pour une charge de travail ETL, une pour une charge de travail d'analyse et une pour une charge de travail de science de données. La charge de travail ETL s'exécute toutes les 6 heures, la charge de travail d'analyse s'exécute tout au long de la journée et la charge de travail de science de données peut connaître des pics à tout moment. La gestion manuelle de la charge de travail vous permet de spécifier la mémoire et la simultanéité de chaque file d'attente de charge de travail, en fonction de votre compréhension de l'importance de chaque charge de travail pour l'entreprise. La spécification de la mémoire et de la simultanéinté est non seulement difficile à comprendre, mais elle se traduit également par le partitionnement statique des ressources du cluster et par conséquent, par leur perte lorsque seul un sous-ensemble des charges de travail s'exécute.

Vous pouvez utiliser une gestion automatique de la charge de travail avec des priorités de requête pour indiquer les priorités relatives des charges de travail, tout en évitant les problèmes précédents. Pour cet exemple, procédez comme suit :

  • Create a new parameter group and switch to Auto WLM mode.

  • Add queues for each of the three workloads: ETL workload, analytics workload, and data science workload. Use the same user groups for each workload that was used with Manual WLM mode.

  • Set the priority for the ETL workload to High, the analytics workload to Normal, and the data science to Low. These priorities reflect your business priorities for the different workloads or user groups.

  • Optionally, enable concurrency scaling for the analytics or data science queue so that queries in these queues get consistent performance even when the ETL workload is executing every 6 hours.

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. Les performances prévisibles d'une charge de travail à priorité élevée s'effectuent au prix de charges de travail à priorité plus faible qui 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 algorithmes de planification utilisés par Amazon Redshift veillent à ce que les requêtes à priorité plus faible ne connaissent pas de pénurie, et poursuivent leur progression à un rythme inférieur.

Note
  • The timeout field is not available in automatic WLM. Instead, use the QMR rule, query_execution_time. For more information, see WLM query monitoring rules.

  • The QMR action, HOP, is not applicable to automatic WLM. Instead, use the change priority action. For more information, see WLM query monitoring rules.

  • Within a parameter group, avoid mixing automatic WLM queues and manual WLM queues. Instead, create a new parameter group when migrating to automatic WLM.