Problembehebung bei Bereitstellungen von SageMaker Amazon-Modellen

Wenn Sie bei der Bereitstellung von Modellen für maschinelles Lernen in Amazon auf ein Problem stoßen SageMaker, lesen Sie die folgenden Anleitungen.

Erkennungsfehler bei der CPU Anzahl der aktiven Benutzer

Wenn Sie ein SageMaker Modell mit einer Linux Java Virtual Machine (JVM) bereitstellen, können Erkennungsfehler auftreten, die die Nutzung der verfügbaren CPU Ressourcen verhindern. Dieses Problem betrifft einigeJVMs, die Java 8 und Java 9 unterstützen, und die meisten, die Java 10 und Java 11 unterstützen. Diese JVMs implementieren einen Mechanismus, der die CPU Anzahl und den maximal verfügbaren Speicher erkennt und verarbeitet, wenn ein Modell in einem Docker-Container und allgemeiner in taskset Linux-Befehlen oder Kontrollgruppen (Cgroups) ausgeführt wird. SageMakerBereitstellungen nutzen einige der Einstellungen, die für die Verwaltung dieser Ressourcen JVM verwendet werden. Derzeit führt dies dazu, dass der Container die Anzahl der verfügbaren CPUs Objekte falsch erkennt.

SageMaker schränkt den Zugriff CPUs auf eine Instanz nicht ein. Es kann jedoch JVM sein, dass die CPU Anzahl erkannt 1 wird, wenn mehr für den Container verfügbar CPUs sind. Infolgedessen JVM passt der alle internen Einstellungen so an, dass er so ausgeführt wird, als ob nur der 1 CPU Kern verfügbar wäre. Diese Einstellungen wirken sich auf die Speicherbereinigung, Sperren, Compiler-Threads und andere JVM interne Funktionen aus, die sich negativ auf die Parallelität, den Durchsatz und die Latenz des Containers auswirken.

Ein Beispiel für die Fehlerkennung: Führen Sie in einem SageMaker dafür konfigurierten Container, der mit einem JVM bereitgestellt wird, der auf Java8_191 basiert und für den vier auf der Instanz verfügbar sindCPUs, den folgenden Befehl aus, um Ihren zu starten: JVM

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

Dies erzeugt die folgende Ausgabe:

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)

Viele Benutzer, die von diesem Problem JVMs betroffen sind, haben die Möglichkeit, dieses Verhalten zu deaktivieren und den vollen Zugriff auf alle Instanzen auf der Instanz wiederherzustellen. CPUs Deaktivieren Sie das unerwünschte Verhalten und richten Sie vollen Zugriff auf alle Instanzen ein, CPUs indem Sie den -XX:-UseContainerSupport Parameter beim Starten von Java-Anwendungen angeben. Führen Sie zum Beispiel den java Befehl aus, um Ihren JVM wie folgt zu starten:

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

Dies erzeugt die folgende Ausgabe:

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)

Prüfen Sie, ob der in Ihrem Container JVM verwendete den -XX:-UseContainerSupport Parameter unterstützt. Wenn ja, übergeben Sie den Parameter immer, wenn Sie Ihren startenJVM. Dadurch erhalten Sie Zugriff CPUs auf alle Ihre Instanzen.

Dieses Problem kann auch auftreten, wenn Sie A indirekt JVM in SageMaker Containern verwenden. Zum Beispiel, wenn Sie a JVM zur Unterstützung von SparkML Scala verwenden. Der -XX:-UseContainerSupport Parameter wirkt sich auch auf die von Java zurückgegebene Ausgabe aus. Runtime.getRuntime().availableProcessors() API

Probleme bei der Bereitstellung einer model.tar.gz-Datei

Wenn Sie ein Modell mithilfe einer model.tar.gz Datei bereitstellen, sollte der Tarball des Modells keine Symlinks enthalten. Symlinks führen dazu, dass das Modell nicht erstellt werden kann. Außerdem empfehlen wir Ihnen, keine unnötigen Dateien in den Tarball aufzunehmen.

Beim primären Container war die Ping-Zustandsprüfungen nicht erfolgreich

Wenn die Ping-Zustandsprüfungen für Ihren primären Container mit der folgenden Fehlermeldung fehlschlagen, deutet dies darauf hin, dass bei Ihrem Container oder Skript ein Problem vorliegt:

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

Um dieses Problem zu beheben, sollten Sie in den CloudWatch Log-Logs für den betreffenden Endpunkt nachsehen, ob Fehler oder Probleme vorliegen, die verhindern, dass der Container auf /ping oder reagiert/invocations. Die Protokolle enthalten ggf. eine Fehlermeldung, die auf das Problem hinweist. Sobald Sie den Fehler und die Gründe für das Fehlschlagen identifiziert haben, sollten Sie den Fehler beheben.

Es empfiehlt sich auch, die Modellbereitstellung lokal zu testen, bevor Sie einen Endpunkt erstellen.

• Verwenden Sie den lokalen Modus in SageMaker SDK, um die gehostete Umgebung nachzuahmen, indem Sie das Modell auf einem lokalen Endpunkt bereitstellen. Weitere Informationen finden Sie unter Lokaler Modus.

• Verwenden Sie Vanilla-Docker-Befehle, um zu testen, ob der Container auf /Ping und /Aufrufe reagiert. Weitere Informationen finden Sie unter local_test.