Meilleures pratiques d'AMP Engine
L'objectif de ce document est de répondre aux questions relatives au nouvel AMP Engine. Le document est destiné aux administrateurs existants et aux nouveaux utilisateurs.
Pour plus d'informations sur AMP Engine, consultez les pages d'aide Alteryx AMP Engine et Moteur .
Pour plus d'informations sur la configuration système requise pour Server, consultez la page d'aide Configuration requise .
Rubriques générales
Dans la plupart des cas d'usage, AMP Engine offre des améliorations significatives en termes de performances et d'efficacité par rapport au moteur d'origine lorsqu'il est doté de ressources système suffisantes. Pour plus d'informations sur les exigences et recommandations en matière de ressources système, consultez les sections Comment gérer les ressources système avec AMP ? et Quelle est la configuration système requise pour AMP Engine ? .
AMP est conçu pour fonctionner avec de plus grands volumes de données à une vitesse plus élevée et exécute généralement des workflows plus rapidement, avec une utilisation plus complète des ressources par rapport au moteur d'origine.
L'architecture du moteur d'origine permet un traitement à thread unique, où vos données sont traitées de façon séquentielle, enregistrement par enregistrement. En revanche, le nouveau concept AMP permet un traitement multi-threaded massif. AMP traite les enregistrements sous forme de paquets pour améliorer les temps d'exécution, et les outils peuvent fonctionner en parallèle. AMP utilise également des algorithmes plus performants lors du regroupement et du tri des enregistrements, ce qui peut affecter l'ordre des enregistrements de sortie.
L'article AMPlifiez vos workflows décrit certains des avantages en termes de performances de l'utilisation d'AMP Engine :
Les outils les plus couramment utilisés sont plus performants avec AMP.
Les avantages tirés d'AMP augmentent généralement au fur et à mesure que la taille des données augmente.
Les performances varient en fonction de la taille des données, du matériel sous-jacent, de l'infrastructure réseau et du centre de données, de la configuration d'Alteryx Server et de la construction des workflows.
Résultats de l'analyse comparative
Note
Pour procéder à l'analyse comparative, nous avons utilisé les mesures suivantes :
Débit du workflow = (workflows /exécution). Le temps d'exécution est la durée totale nécessaire à l'exécution d'un workflow.
Débit du moteur = (workflows / moteur_exécution). Moteur_exécution est l'heure à laquelle le moteur exécute un workflow.
Workflows = nombre de workflows.
Lorsqu'il n'y a qu'un seul workflow, il n'y a pas de différence de temps significative entre le débit du moteur et le débit du workflow. S'il y a deux workflows dans une file d'attente avec un seul worker, l'exécution du premier workflow affecte l'exécution du second.
Résultats de l'analyse comparative pour une tâche de préparation de données type
Résultats de l'analyse comparative pour une tâche prédictive ou de Machine Learning à forte intensité du processeur
Pour plus d'informations, reportez-vous aux liens vers la documentation au bas de ce document.
Designer a activé AMP par défaut pour les nouveaux workflows. Pour les nouvelles installations de Server ou les nouveaux workers sur des Servers existants, la valeur par défaut sera d'autoriser l'exécution d'AMP et du moteur d'origine. Les paramètres de workflow déterminent le moteur utilisé.
1. Controller (Contrôleur) > General (Général) > Enable AMP Engine (Activer AMP Engine)
1. Avant la mise à niveau, notez vos paramètres actuels.
2. Après la mise à niveau, restaurez la sélection à la valeur souhaitée.
2. Worker > General (Général) > Allow Server to manage workflows running simultaneously (Autoriser Server à gérer les workflows s'exécutant simultanément)
1. Avant la mise à niveau, notez le nombre défini de workflows autorisés à s'exécuter simultanément.
2. Après la mise à niveau, désélectionnez « Allow Server to manage workflows running simultaneously » (Autoriser Server à gérer les workflows s'exécutant simultanément).
3. Entrez le nombre de workflows autorisés à s'exécuter simultanément que vous avez noté.
3. Engine (Moteur) > General (Général) > Engine (Moteur)
1. Avant la mise à niveau, notez vos paramètres actuels.
2. Après la mise à niveau, restaurez la sélection à la valeur souhaitée.
4. Engine (Moteur) > General (Général) > Run engine at a lower priority (Exécuter le moteur en basse priorité)
1. Avant la mise à niveau, notez vos paramètres actuels.
2. Après la mise à niveau, restaurez la sélection à la valeur souhaitée.
Nous vous recommandons d'utiliser les nouvelles options Allow Server to manage workflows running simultaneously (Autoriser Server à gérer les ressources s'exécutant simultanément) et Allow Server to manage engine resources (Autoriser Server à gérer les ressources du moteur). Nous avons ajouté une logique pour que chaque instance de moteur fonctionne dans les limites de la mémoire et les contraintes de processeur logique définies dans les paramètres système . Les administrateurs doivent veiller à ne pas surallouer les ressources s'ils définissent ces valeurs manuellement au lieu de laisser Server les gérer.
Calculs
Lorsque vous activez les options Allow Server to manager workflows running simultaneously (Autoriser Server à gérer les workflows s'exécutant simultanément) et Allow Server to manage engine resources (Autoriser Server à gérer les ressources du moteur), Server calcule le nombre de tâches simultanées, ainsi que les threads de processeur (cœurs) et la quantité de mémoire à allouer par tâche au démarrage du service. Ces calculs sont basés sur le nombre total de cœurs de processeur logique disponibles et sur le nombre total de ressources mémoire du système sur la machine hôte. Ils sont également conçus pour optimiser les performances d'AMP pour le matériel disponible en fonction des résultats de notre analyse comparative. Les formules de ces calculs sont les suivantes :
Note
Tâches simultanées
nombre de tâches simultanées = min(floor(processeurs logiques / 8), (floor(mémoire totale / 8000) - 2))
Limite de la mémoire
limite de mémoire = floor(mémoire totale / (nombre de tâches simultanées +2))
Threads de traitement
threads = floor(nombre total de processeurs logiques / nombre de tâches simultanées)
Recommandations de réglage manuel de la valeur
Nous vous recommandons de suivre les instructions suivantes pour bénéficier de performances optimales lorsque vous définissez manuellement ces valeurs :
Mémoire par workflow en cours d'exécution : la recommandation minimale est de 8 Go par workflow pour des performances optimales avec AMP.
Processeur par workflow en cours d'exécution : 1 workflow en cours d'exécution simultanée pour 6 à 8 cœurs CPU logiques.
Nombre maximal de moteurs AMP s'exécutant en parallèle : dépend entièrement du matériel. En théorie, vous pouvez exécuter 16 tâches AMP ou tâches AMP et de moteur d'origine combinées à la fois si vous avez un worker avec 128 cœurs logiques et 160 Go de RAM. Cependant, à ce stade, les E/S de disque et la bande passante du réseau sont plus susceptibles de constituer le goulet d'étranglement. Les performances du moteur d'origine et d'AMP seront limitées par les E/S du disque et la bande passante du réseau en fonction de la taille des données, de leur provenance et de leur destination de sortie.
Nombre maximal de moteurs AMP exécutés tout en exécutant E1 : Server ne fait pas la différence entre une tâche AMP Engine et une tâche du moteur d'origine. Server envoie simplement le workflow au moteur et le moteur détermine s'il doit s'exécuter via AMP ou le moteur d'origine. De ce fait, Server suppose que toutes les tâches sont AMP si AMP Engine est activé.
Nous vous recommandons de réserver une quantité de mémoire équivalente à une tâche pour le système d'exploitation, et une quantité de mémoire équivalente à une tâche supplémentaire pour éviter un impact négatif si vous exécutez manuellement un workflow depuis Designer exécuté sur Server. Nos formules de calcul des ressources tiennent déjà compte de ces recommandations.
Pour connaître les dernières recommandations de configuration système requise pour Server, consultez la page d'aide Configuration requise pour Server . Nous avons divisé nos recommandations en deux catégories : Configuration matérielle minimale requise et Matériel recommandé pour des performances optimales .
Configuration matérielle minimale requise
La configuration matérielle minimale requise de Server correspond au matériel minimal requis pour exécuter une installation stable d'Alteryx Server. Si vous ne respectez pas les exigences minimales, vous risquez de connaître des performances médiocres et un arrêt aléatoire du service sur n'importe quel nœud sur lequel le moteur s'exécute.
Les configurations matérielles minimales recommandées selon le nombre souhaité de workflows simultanés sont les suivantes :
Note
La ligne surlignée en vert correspond à la configuration minimale recommandée. La ligne contenant les informations relatives à un workflow simultané vous permet de comprendre dans quelle mesure vous devez augmenter les ressources pour ajouter une tâche supplémentaire à la configuration existante.
Matériel recommandé pour des performances optimales
Les recommandations matérielles de performances optimales de Server correspondent au matériel minimal idéal requis pour que Server optimise l'exécution des workflows lors de l'utilisation d'AMP Engine. Ceci est utile pour éliminer la congestion sur les systèmes très sollicités et optimiser les performances d'AMP Engine et les capacités de débit.
Pour des performances optimales, nous recommandons les paramètres matériels suivants :
Note
*Les cœurs logiques sont soit des processeurs virtuels, soit des cœurs logiques au sein d'un cœur physique. La normalisation des cœurs logiques permet de comparer de manière cohérente les serveurs physiques sur site et les serveurs virtuels dans le cloud.
Dans les versions antérieures à 2022.1, AMP était disponible sur Server, mais désactivé par défaut.
Depuis la version 2022.1, sur les nouvelles installations de Server, le contrôleur et le worker autorisent par défaut l'exécution d'AMP et du moteur d'origine. Pour les Servers existants, les paramètres du contrôleur et du worker en vigueur peuvent changer. Les nouveaux workers peuvent avoir l'exécution d'AMP et du moteur d'origine activée par défaut. Si vous souhaitez éviter cela, consultez la section expliquant comment conserver les paramètres actuels.
Les paramètres d'activation d'AMP Engine dans les nœuds de contrôleur et de worker se trouvent dans les paramètres système Alteryx. Il existe désormais des paramètres supplémentaires pour la gestion des allocations matérielles pour chaque moteur. Il existe également un paramètre recommandé pour autoriser Server à gérer les ressources du moteur .
Paramètres système pour les installations de Server existantes :
Controller (Contrôleur) > General (Général) > Enable AMP Engine (Activer AMP Engine) : si vous avez déjà modifié cette valeur, la nouvelle valeur sera persistante après la mise à niveau, et ce quelle que soit la modification. Si vous n'avez jamais modifié ce paramètre et que vous avez toujours laissé l'état par défaut non sélectionné, la case à cocher sera alors sélectionnée, ce qui signifie qu'AMP est activé par défaut.
Le paramètre Worker > General (Général) > Allow Server to manage workflows running simultaneously (Autoriser Server à gérer les workflows s'exécutant simultanément) prend par défaut la valeur True (Vrai) pour tous les workers. Lorsque ce paramètre est défini sur True, vous ne pouvez pas définir le nombre de workers autorisés à s'exécuter simultanément.
Le nombre de workers pouvant s'exécuter simultanément ( Workers allowed to run simultaneously ) est automatiquement calculé au démarrage du service en fonction du processeur et de la mémoire disponibles dans l'environnement Server.
Engine (Moteur) > General (Général) > Engine (Moteur) : si le client a déjà changé cette valeur, la nouvelle valeur sera persistante après la mise à niveau, et ce quelle que soit la modification. Si le client n'a jamais modifié ce paramètre et a toujours utilisé l'option par défaut du moteur d'origine, la nouvelle valeur par défaut sera définie sur Both Engines (Les deux moteurs).
Engine (Moteur) > General (Général) > Allow Server to manage engine resources (Autoriser Server à gérer les ressources du moteur) est un nouveau paramètre qui est défini par défaut sur False (Faux).
La formule Engine (Moteur) > General (Général) > Memory Limit (Limite de mémoire) qui permet de calculer la valeur par défaut a été modifiée.
La formule Engine (Moteur) > General (Général) > Default number of processing threads (Nombre de threads de traitement par défaut) qui permet de calculer la valeur par défaut a été modifiée.
Engine (Moteur) > General (Général) > Run engine at a lower priority (Exécuter le moteur en basse priorité) : si le client a déjà changé cette valeur, la nouvelle valeur sera persistante après la mise à niveau, et ce quelle que soit la modification. Si le client a toujours utilisé la valeur par défaut False, après la mise à niveau, la nouvelle valeur par défaut sera définie sur True .
Paramètres système pour les nouvelles installations de Server :
La case à cocher Controller (Contrôleur) > General (Général) > Enable AMP Engine (Activer AMP Engine) est par défaut définie sur True .
Le paramètre Worker > General (Général) > Allow Server to manage workflows running simultaneously (Autoriser Server à gérer les workflows s'exécutant simultanément) prend par défaut la valeur True (Vrai) pour tous les workers.
Le nombre de workers pouvant s'exécuter simultanément ( Workers allowed to run simultaneously ) est automatiquement calculé au démarrage du service en fonction du processeur et de la mémoire disponibles dans l'environnement Server.
La liste déroulante Engine (Moteur) > General (Général) > Engine (Moteur) affiche par défaut Both Engines (Les deux moteurs).
Le paramètre Engine (Moteur) > General (Général) > Allow Server to manage engine resources (Autoriser Server à gérer les ressources du moteur) est défini par défaut sur False .
La formule Engine (Moteur) > General (Général) > Memory Limit (Limite de mémoire) qui permet de calculer la valeur par défaut a été modifiée.
La formule Engine (Moteur) > General (Général) > Default number of processing threads (Nombre de threads de traitement par défaut) qui permet de calculer la valeur par défaut a été modifiée.
Le paramètre Engine (Moteur) > General (Général) > Run engine at a lower priority (Exécuter le moteur en basse priorité) est défini par défaut sur True .
Les utilisateurs peuvent-ils rétablir les paramètres modifiés (c.-à.-d., désactiver AMP dans Server) ?
Si l'administrateur ne veut pas utiliser AMP, il doit le désactiver manuellement. Voir l'image ci-dessous pour visualiser le paramètre Engine dans la section Configuration générale du contrôleur des paramètres système.
Si l'administrateur souhaite désactiver AMP sur certains nœuds de worker, il peut procéder à l'opération dans la section Engine Configuration (Configuration du moteur) des paramètres système. Voir ci-dessous la liste déroulante du paramètre Engine. Dans l'image ci-dessous, il est défini sur Both Engines , mais peut être modifié pour sélectionner le moteur d'origine Original Engine uniquement. Both Engines est la valeur par défaut dans un nouvel environnement Server.
Il n'y a pas de limite de mémoire distincte. Dans Paramètres système , le champ Engine (Moteur) > General (Général) > Memory Limit (Limite de mémoire) s'applique au moteur. Il s'applique à la fois à Designer et Server, soit à toute application où le moteur s'exécute.
Designer n'exécute qu'un seul workflow à la fois. Les limitations sont donc différentes et plus tolérantes.
AMP est automatiquement activé sur le système et tous les paramètres pertinents sont configurés par défaut. Les modifications sont uniquement nécessaires s'ils souhaitent le désactiver. Reportez-vous aux réponses de la section Quelles sont les modifications apportées à Designer et à Server ?
Assurez-vous de respecter les directives de la configuration matérielle minimale requise pour des performances et une stabilité optimales.
L'activation d'AMP dans Server entraînera-t-elle l'échec de l'un de mes workflows existants ?
Non, ils s'exécuteront exactement de la même manière qu'auparavant.
Le fait d'autoriser l'exécution d'AMP et du moteur d'origine sur Server risque-t-il de modifier le fonctionnement de mes workflows existants ?
Lorsqu'un workflow est enregistré dans Designer, l'option de paramètre Exécution est d'utiliser AMP Engine ou non. Quelle que soit l'option enregistrée dans Designer, elle est prise en compte lors de l'exécution dans Server. Server ne remplace jamais l'option de moteur du workflow. Par conséquent, l'autorisation d'exécuter AMP et le moteur d'origine sur Server n'entraîne pas pour autant l'exécution de workflows avec le moteur AMP Engine si ces derniers ont été enregistrés comme moteur d'origine. Par conséquent, si AMP est l'option de moteur enregistrée pour un workflow, mais qu'elle n'est pas activée dans Server, le workflow NE s'exécute PAS avec le moteur d'origine et l'exécution échoue.
Pour qu'un workflow précédemment enregistré comme moteur d'origine s'exécute en tant qu'AMP, il doit être à nouveau enregistré dans Designer avec le paramètre Utiliser AMP Engine sélectionné.
L'exécution de workflows dans AMP peut modifier l'ordre des lignes de sortie résultantes, car certaines opérations sont désormais effectuées en parallèle. Gardez cela présent à l'esprit et vérifiez si vos processus dépendent de l'ordre de sortie. Si c'est le cas, vous pouvez régler vos workflows pour garantir l'ordre du moteur d'origine.
Vous pouvez vous attendre à des changements concernant la durée d'exécution de chaque workflow.
En général, les tâches de workflow AMP s'exécuteront beaucoup plus rapidement avec le nombre de cœurs de traitement approprié.
Dans certains cas, les tâches AMP pourront prendre plus de temps que celles du moteur d'origine, en particulier si les workflows sont gourmands en CPU et que le nombre de threads par workflow est faible.
Bien qu'en général, le délai d'exécution de vos workflows sera plus court, l'exécution d'un workflow non-AMP pourra être plus long, puisqu'un workflow AMP concurrent lui prendra des ressources. Cependant, cela n'a aucune incidence sur le fonctionnement de la qualité de service (QoS) et certains workflows pourront s'exécuter plus rapidement. La QoS continuera de fonctionner comme elle l'a toujours fait.
Cela est-il envisageable lorsqu'AMP est activé ?
Le délai de réalisation devrait toujours être meilleur, à quelques exceptions près, où la synchronisation est plus longue.
Si l'activation d'AMP ne permet plus de garantir des délais d'exécution constants, faut-il recommander aux utilisateurs concernés de désactiver AMP ?
Si les ressources sont suffisantes, les workflows AMP et du moteur d'origine doivent être prévisibles (selon une nouvelle référence, au lieu de se limiter aux seuls résultats historiques des performances du moteur d'origine). L'imprévisibilité résulterait uniquement d'une sous-allocation de ressources matérielles d'un worker (moteur d'origine et AMP étant en concurrence pour les ressources).
Il est possible d'enregistrer le workflow sur Server avec AMP activé, puis d'en enregistrer une copie avec AMP désactivé. Exécutez ensuite plusieurs fois chaque workflow pour identifier le plus performant. Notez également que les workflows AMP ont tendance à s'exécuter plus rapidement lorsqu'ils sont exécutés en même temps que d'autres workflows AMP.
Problèmes liés à la qualité de service
L'option Engine Configuration Memory Limit (Limite de mémoire de la configuration du moteur) s'applique au moteur, qu'il soit d'origine ou AMP. La différence réside dans la façon dont chaque moteur gère la limite de mémoire :
Le moteur d'origine préalloue la totalité de la limite.
Le moteur AMP alloue ce dont il a besoin jusqu'à la limite de mémoire.
L'utilisation des ressources est plus efficace. Le moteur d'origine est multithread, mais pas hautement multithread. AMP est bien plus performant pour exécuter des tâches en série. Les avantages résident dans le débit total qui est plus élevé avec AMP qu'avec le moteur d'origine.
Server est désormais capable d'analyser votre matériel et d'allouer les ressources appropriées par moteur. Cette capacité n'est pas du même niveau que celle d'un gestionnaire de ressources de système d'exploitation. Néanmoins, grâce à cette nouvelle fonctionnalité, Server est maintenant capable de gérer vos ressources.
Si l'administrateur le configure, nous allouons automatiquement le nombre de tâches autorisées à s'exécuter simultanément en fonction des ressources matérielles disponibles. Pour plus d'informations sur la configuration des workers, reportez-vous à la page d'aide Worker .
Non, les ressources sont allouées par tâche de moteur. Chaque tâche se voit allouer ses propres ressources. Cela signifie qu'il ne doit pas exister de conflit de ressources entre les tâches.
Articles relatifs à AMP
Webinaire relatif à AMP Engine (32 minutes)
Alteryx Engine et AMP : principales différences
Utilisation de la mémoire par AMP
Accélérez vos processus analytiques avec le nouveau AMP Engine
Technique approfondie d'AMP Engine | Partie 1 | Pourquoi AMP ?
Technique approfondie d'AMP Engine | Partie 2 | Concepts clés d'AMP Engine