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.

Résoudre les problèmes liés aux déploiements de SageMaker modèles Amazon

Si vous rencontrez un problème lors du déploiement de modèles de machine learning sur Amazon SageMaker, consultez les instructions suivantes.

Erreurs de détection dans le CPU décompte actif

Si vous déployez un SageMaker modèle avec une machine virtuelle Java Linux (JVM), vous risquez de rencontrer des erreurs de détection qui empêchent l'utilisation CPU des ressources disponibles. Ce problème concerne certaines JVMs versions compatibles avec Java 8 et Java 9, et la plupart avec Java 10 et Java 11. Ils JVMs implémentent un mécanisme qui détecte et gère le CPU nombre et la mémoire maximale disponible lors de l'exécution d'un modèle dans un conteneur Docker et, plus généralement, au sein de taskset commandes Linux ou de groupes de contrôle (cgroups). SageMakerles déploiements tirent parti de certains paramètres JVM utilisés pour gérer ces ressources. Actuellement, cela fait que le conteneur détecte de manière incorrecte le nombre de produits disponiblesCPUs.

SageMaker ne limite pas l'accès CPUs à une instance. Cependant, il est JVM possible qu'ils détectent le CPU nombre 1 lorsqu'il en CPUs existe d'autres pour le conteneur. Par conséquent, le JVM ajuste tous ses paramètres internes pour fonctionner comme si seul le 1 CPU noyau était disponible. Ces paramètres affectent la collecte des déchets, les verrous, les threads du compilateur et d'autres JVM éléments internes qui ont un impact négatif sur la simultanéité, le débit et la latence du conteneur.

Pour un exemple d'erreur de détection, dans un conteneur configuré pour SageMaker être déployé avec un JVM conteneur basé sur Java8_191 et dont quatre sont disponibles CPUs sur l'instance, exécutez la commande suivante pour démarrer votre : JVM

java -XX:+UnlockDiagnosticVMOptions -XX:+PrintActiveCpus -version

Voici le résultat obtenu :

active_processor_count: sched_getaffinity processor count: 4
active_processor_count: determined by OSContainer: 1
active_processor_count: sched_getaffinity processor count: 4
active_processor_count: determined by OSContainer: 1
active_processor_count: sched_getaffinity processor count: 4
active_processor_count: determined by OSContainer: 1
active_processor_count: sched_getaffinity processor count: 4
active_processor_count: determined by OSContainer: 1
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-8u191-b12-2ubuntu0.16.04.1-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

La plupart des JVMs personnes concernées par ce problème ont la possibilité de désactiver ce comportement et de rétablir un accès complet à tous les éléments de CPUs l'instance. Désactivez le comportement indésirable et établissez un accès complet à toutes les instances CPUs en incluant le -XX:-UseContainerSupport paramètre lors du démarrage des applications Java. Par exemple, exécutez la java commande pour démarrer JVM comme suit :

java -XX:-UseContainerSupport -XX:+UnlockDiagnosticVMOptions -XX:+PrintActiveCpus -version

Voici le résultat obtenu :

active_processor_count: sched_getaffinity processor count: 4
active_processor_count: sched_getaffinity processor count: 4
active_processor_count: sched_getaffinity processor count: 4
active_processor_count: sched_getaffinity processor count: 4
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-8u191-b12-2ubuntu0.16.04.1-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

Vérifiez si le produit JVM utilisé dans votre conteneur prend en charge le -XX:-UseContainerSupport paramètre. Si c'est le cas, transmettez toujours le paramètre lorsque vous démarrez votreJVM. Cela permet d'accéder à tous les éléments CPUs de vos instances.

Vous pouvez également rencontrer ce problème lors de l'utilisation indirecte d'un JVM dans SageMaker des conteneurs. Par exemple, lorsque vous utilisez un JVM pour prendre en charge SparkML Scala. Le -XX:-UseContainerSupport paramètre affecte également la sortie renvoyée par le Java Runtime.getRuntime().availableProcessors() API.

Problèmes liés au déploiement d'un fichier model.tar.gz

Lorsque vous déployez un modèle à l'aide d'un fichier model.tar.gz, l'archive du modèle ne doit pas inclure de liens symboliques. Les liens symboliques entraînent l'échec de la création du modèle. Nous vous recommandons également de ne pas inclure de fichiers inutiles dans l'archive.

Le conteneur principal n'a pas passé les surveillances de l'état ping

Si le message d'erreur suivant affiche un échec des surveillances de l'état ping pour votre conteneur principal, cela indique un problème lié à votre conteneur ou à votre script :

The primary container for production variant beta did not pass the ping health check. Please check CloudWatch Logs logs for this endpoint.

Pour résoudre ce problème, vous devez consulter les CloudWatch journaux du point de terminaison en question pour voir s'il existe des erreurs ou des problèmes empêchant le conteneur de répondre à /ping ou/invocations. Les journaux peuvent fournir un message d'erreur qui pourrait indiquer le problème. Une fois que vous avez identifié l'erreur et la raison de l'échec, vous devez résoudre l'erreur.

Il est également recommandé de tester le déploiement du modèle localement avant de créer un point de terminaison.