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 du nombre d'UC actives

Si vous déployez un SageMaker modèle avec une machine virtuelle Java (JVM) Linux, vous risquez de rencontrer des erreurs de détection empêchant l'utilisation des ressources CPU disponibles. Ce problème affecte certaines machines virtuelles Java qui prennent en charge Java 8 et Java 9, et la plupart de celles qui prennent en charge Java 10 et Java 11. Ces machines virtuelles virtuelles implémentent un mécanisme qui détecte et gère le nombre de processeurs 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 utilisés par la JVM pour gérer ces ressources. Actuellement, ce problème empêche le conteneur de détecter correctement le nombre d'UC disponibles.

SageMaker ne limite pas l'accès aux processeurs d'une instance. Toutefois, la machine virtuelle Java peut détecter 1 UC alors qu'un nombre plus important est disponible pour le conteneur. La machine virtuelle Java ajuste alors l'ensemble de ses paramètres internes afin de s'exécuter comme si 1 seul le processeur central était disponible. Ces paramètres affectent le nettoyage de la mémoire, les verrous, les threads de compilateur et d'autres paramètres internes de la machine virtuelle Java qui ont un effet 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é à SageMaker cet effet déployé avec une JVM basée sur Java8_191 et disposant de quatre processeurs disponibles 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 machines virtuelles Java affectées par ce problème disposent d'une option pour désactiver ce comportement et rétablir l'accès complet à l'ensemble des UC sur l'instance. Désactivez le comportement indésirable et établissez un accès total à toutes les UC de l'instance en incluant le paramètre -XX:-UseContainerSupport lorsque vous démarrez des applications Java. Par exemple, exécutez la commande java pour démarrer votre machine virtuelle Java 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 la machine virtuelle Java utilisée dans votre conteneur prend en charge le paramètre -XX:-UseContainerSupport. Si c'est le cas, transmettez toujours le paramètre lorsque vous démarrez votre machine virtuelle Java. Cela permet d'accéder à l'ensemble des UC de vos instances.

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

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.

• Utilisez le mode local dans le SageMaker SDK pour imiter l'environnement hébergé en déployant le modèle sur un point de terminaison local. Pour plus d'informations, consultez Mode local (langue française non garantie).

• Utilisez les commandes Docker Vanilla pour tester si le conteneur répond aux commandes /ping et /invocations. Pour plus d'informations, consultez local_test (langue française non garantie).