Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Propriétés de configuration dynamiques et statiques WLM
Les propriétés de la configuration WLM sont dynamiques ou statiques. Vous pouvez appliquer des propriétés dynamiques à la base de données sans redémarrage du cluster, mais les propriétés statiques nécessitent un redémarrage du cluster pour que les modifications prennent effet. Cependant, si vous modifiez les propriétés dynamiques et statiques en même temps, vous devez redémarrer le cluster pour que toutes les modifications prennent effet. Cela se vérifie que les propriétés soient statiques ou dynamiques.
Pendant l’application des propriétés dynamiques, votre cluster a le statut `modifying`. Le basculement entre la gestion automatique de la charge de travail et la gestion manuelle de la charge de travail est une modification statique et nécessite une réinitialisation de cluster pour être pris en compte.
La table suivante indique si les propriétés WLM sont dynamiques ou statiques lors de l’utilisation de la gestion automatique ou manuelle de la charge de travail.
****
| Propriété WLM | Gestion automatique de la charge de travail | Gestion manuelle de la charge de travail |
| --- | --- | --- |
| Groupes de requêtes | Répartition dynamique | Statique |
| Caractère générique de groupe de requêtes | Répartition dynamique | Statique |
| Groupes d’utilisateurs | Répartition dynamique | Statique |
| Caractère générique de groupe d’utilisateurs | Répartition dynamique | Statique |
| Rôles utilisateurs | Répartition dynamique | Statique |
| Caractère générique du rôle utilisateur | Répartition dynamique | Statique |
| Concurrency on main (Simultanéité sur cluster principal) | Non applicable | Répartition dynamique |
| Mode de mise à l’échelle de la simultanéité | Répartition dynamique | Répartition dynamique |
| Activer l’accélération des requêtes courtes | Non applicable | Répartition dynamique |
| Durée d’exécution maximale pour les requêtes courtes | Répartition dynamique | Répartition dynamique |
| Pourcentage de mémoire à utiliser | Non applicable | Répartition dynamique |
| Timeout | Non applicable | Répartition dynamique |
| Priority | Répartition dynamique | Non applicable |
| Ajout ou suppression de files d’attente | Répartition dynamique | Statique |
Si vous ajoutez une règle de surveillance des requêtes (QMR), ou que vous modifiez ou supprimez une règle de surveillance des requêtes existante, le changement se fait automatiquement sans qu’il soit nécessaire de redémarrer le cluster.
**Note**
Lors de l’utilisation de la gestion manuelle de charge de travail, si la valeur du délai d’attente est modifiée, la nouvelle valeur est appliquée à toute requête dont l’exécution démarre une fois que la valeur a été modifiée. Si la simultanéité ou le pourcentage de mémoire à utiliser sont modifiés, Amazon Redshift passe à la nouvelle configuration de manière dynamique. Les requêtes en cours d’exécution ne sont donc pas affectées par le changement. Pour plus d’informations, consultez [Allocation de mémoire dynamique WLM.](https://docs.aws.amazon.com/redshift/latest/dg/cm-c-wlm-dynamic-memory-allocation.html)
**Topics**
+ [Allocation de mémoire dynamique WLM](cm-c-wlm-dynamic-memory-allocation.md)
+ [Exemple WLM dynamique](cm-c-wlm-dynamic-example.md)
# Allocation de mémoire dynamique WLM
Dans chaque file d’attente, WLM crée un certain nombre d’emplacements de requêtes équivalant au niveau de simultanéité de la file d’attente. La quantité de mémoire allouée à un emplacement de requête équivaut au pourcentage de mémoire allouée à la file d’attente divisé par le nombre d’emplacements. Si vous modifiez l’allocation de mémoire ou la simultanéité, Amazon Redshift gère dynamiquement la transition vers la nouvelle configuration de WLM. Les requêtes actives peuvent donc s’exécuter jusqu’à ce qu’elles soient terminées en utilisant la quantité de mémoire actuellement allouée. Dans le même temps, Amazon Redshift veille à ce que l’utilisation totale de la mémoire ne dépasse jamais 100 % de la mémoire disponible.
Le gestionnaire de la charge de travail utilise le processus suivant pour gérer la transition.
1. WLM recalcule l’allocation de mémoire de chaque nouvel emplacement de requête.
1. Si un emplacement de requête n’est pas utilisé activement par une requête en cours d’exécution, WLM supprime l’emplacement, ce qui fournit de la mémoire disponible pour les nouveaux emplacements.
1. Si un emplacement de requête est activement en cours d’utilisation, WLM attend la fin de la requête.
1. A mesure que les requêtes actives prennent fin, les emplacements vides sont supprimés et la mémoire associée est libérée.
1. Lorsque suffisamment de mémoire est disponible pour ajouter un ou plusieurs emplacements, de nouveaux emplacements sont ajoutés.
1. Une fois que toutes les requêtes qui étaient en cours d’exécution au moment de la modification prennent fin, le nombre d’emplacements équivaut au nouveau niveau de simultanéité, et la transition vers la nouvelle configuration WLM est terminée.
Dans les faits, les requêtes en cours d’exécution au moment de la modification continuent d’utiliser l’allocation de mémoire d’origine. Les requêtes en file d’attente au moment de la modification sont dirigées vers de nouveaux emplacements, au fur et à mesure qu’ils deviennent disponibles.
Si les propriétés dynamiques WLM sont modifiées au cours du processus de transition, WLM commence immédiatement à passer à la nouvelle configuration, à partir de l’état actuel. Pour afficher le statut de la transition, interrogez la table système [STV\$1WLM\$1SERVICE\$1CLASS\$1CONFIG](r_STV_WLM_SERVICE_CLASS_CONFIG.md).
# Exemple WLM dynamique
Avec Amazon Redshift, vous pouvez gérer automatiquement la distribution de la charge de travail et l’allocation des ressources sur vos clusters Amazon Redshift à l’aide de la gestion dynamique de la charge de travail (WLM dynamique). La gestion dynamique de la charge de travail est un exemple de configuration de gestion de la charge de travail (WLM) qui ajuste dynamiquement les allocations de mémoire en fonction des demandes de charge de travail, permettant ainsi une simultanéité et des performances optimales. La section suivante fournit des informations sur la mise en œuvre et la configuration de la gestion dynamique de la charge de travail pour vos clusters Amazon Redshift.
Supposons que votre cluster WLM soit configuré avec deux files d’attente, à l’aide des propriétés dynamiques suivantes.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/cm-c-wlm-dynamic-example.html)
Supposons à présent que votre cluster dispose de 200 Go de mémoire disponible pour le traitement de la requête. (Ce nombre est arbitraire et utilisé à titre d’illustration uniquement.) Comme le montre l’équation suivante, chaque emplacement se voit allouer 25 Go.
```
(200 GB * 50% ) / 4 slots = 25 GB
```
Ensuite, vous modifiez votre WLM pour utiliser les propriétés dynamiques suivantes.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/cm-c-wlm-dynamic-example.html)
Comme le montre l’équation suivante, la nouvelle allocation de mémoire de chaque emplacement de la file d’attente 1 est de 50 Go.
```
(200 GB * 75% ) / 3 slots = 50 GB
```
Supposons que les requêtes A1, A2, A3 et A4 soient en cours d’exécution lorsque la nouvelle configuration est appliquée, et que les requêtes B1, B2, B3 et B4 sont mises en file d’attente. WLM reconfigure dynamiquement les emplacements de requêtes comme suit.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/cm-c-wlm-dynamic-example.html)
1. WLM recalcule l’allocation de mémoire de chaque emplacement de requête. À l’origine, la file d’attente 1 s’est vue allouer 100 Go. La nouvelle file d’attente dispose d’une allocation totale de 150 Go, elle a donc immédiatement 50 Go disponibles. La file d’attente 1 utilise à présent quatre emplacements, et le nouveau niveau de simultanéité est de trois emplacements, aucun nouvel emplacement n’est donc ajouté.
1. Lorsqu’une requête se termine, l’emplacement est supprimé et 25 Go sont libérés. La file d’attente 1 compte à présent trois emplacements et 75 Go de mémoire disponible. La nouvelle configuration nécessite 50 Go pour chaque nouvel emplacement, mais le nouveau niveau de simultanéité est de trois emplacements, aucun nouvel emplacement n’est donc ajouté.
1. Lorsqu’une deuxième requête se termine, l’emplacement est supprimé et 25 Go sont libérés. La file d’attente 1 compte à présent deux emplacements et 100 Go de mémoire disponible.
1. Un nouvel emplacement est ajouté à l’aide des 50 Go de mémoire disponible. La file d’attente 1 compte à présent trois emplacements et 50 Go de mémoire libre. Les requêtes mises en file d’attente peuvent désormais être acheminées vers le nouvel emplacement.
1. Lorsqu’une troisième requête se termine, l’emplacement est supprimé et 25 Go sont libérés. La file d’attente 1 compte à présent deux emplacements et 75 Go de mémoire disponible.
1. Un nouvel emplacement est ajouté à l’aide des 50 Go de mémoire disponible. La file d’attente 1 compte à présent trois emplacements et 25 Go de mémoire libre. Les requêtes mises en file d’attente peuvent désormais être acheminées vers le nouvel emplacement.
1. Lorsqu’une quatrième requête se termine, l’emplacement est supprimé et 25 Go sont libérés. La file d’attente 1 compte à présent deux emplacements et 50 Go de mémoire disponible.
1. Un nouvel emplacement est ajouté à l’aide des 50 Go de mémoire disponible. La file d’attente 1 compte à présent trois emplacements de 50 Go chacun et toute la mémoire disponible a été allouée.
La transition est terminée, et tous les emplacements de requêtes sont disponibles pour les requêtes mises en file d’attente.