Risolvi i problemi relativi alle implementazioni dei modelli Amazon SageMaker

Se riscontri un problema durante la distribuzione di modelli di machine learning in Amazon SageMaker, consulta le seguenti linee guida.

Errori di rilevamento nel conteggio attivo CPU

Se si distribuisce un SageMaker modello con una Java Virtual Machine Linux (JVM), è possibile che si verifichino errori di rilevamento che impediscono l'utilizzo delle risorse disponibili. CPU Questo problema riguarda alcuni JVMs che supportano Java 8 e Java 9 e la maggior parte che supporta Java 10 e Java 11. Questi JVMs implementano un meccanismo che rileva e gestisce il CPU conteggio e la memoria massima disponibile quando si esegue un modello in un contenitore Docker e, più in generale, all'interno di taskset comandi o gruppi di controllo Linux (cgroup). SageMakerle distribuzioni sfruttano alcune delle impostazioni JVM utilizzate per la gestione di queste risorse. Attualmente, ciò fa sì che il contenitore rilevi erroneamente il numero di unità disponibili. CPUs

SageMaker non limita l'accesso a CPUs su un'istanza. Tuttavia, JVM potrebbe rilevare il CPU conteggio 1 quando ne CPUs sono disponibili altri per il contenitore. Di conseguenza, JVM regola tutte le sue impostazioni interne in modo che vengano eseguite come se fosse disponibile solo il 1 CPU core. Queste impostazioni influiscono sulla raccolta dei rifiuti, sui blocchi, sui thread del compilatore e su altri elementi JVM interni che influiscono negativamente sulla concorrenza, sulla velocità effettiva e sulla latenza del contenitore.

Per un esempio di rilevamento errato, in un contenitore configurato per SageMaker questo e distribuito con un sistema basato su Java8_191 e JVM che ne ha quattro disponibili sull'istanza, esegui il comando seguente per avviare: CPUs JVM

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

Questo comando genera l'output seguente:

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)

Molte delle JVMs persone interessate da questo problema hanno la possibilità di disabilitare questo comportamento e ristabilire l'accesso completo a tutti i componenti dell'istanza. CPUs Disabilita il comportamento indesiderato e stabilisci l'accesso completo a tutte le istanze CPUs includendo il -XX:-UseContainerSupport parametro all'avvio delle applicazioni Java. Ad esempio, esegui il java comando per avviare il tuo JVM come segue:

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

Questo comando genera l'output seguente:

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)

Controlla se quello JVM usato nel tuo contenitore supporta il -XX:-UseContainerSupport parametro. Se lo fa, passa sempre il parametro quando avvii il tuoJVM. Ciò fornisce l'accesso a tutti i file CPUs presenti nelle tue istanze.

Potresti riscontrare questo problema anche quando utilizzi indirettamente a JVM in SageMaker container. Ad esempio, quando si utilizza JVM a per supportare SparkML Scala. Il -XX:-UseContainerSupport parametro influisce anche sull'output restituito da Java Runtime.getRuntime().availableProcessors() API.

Problemi con la distribuzione di un file model.tar.gz

Quando si distribuisce un modello utilizzando un file model.tar.gz, l'archivio del modello non deve includere alcun collegamento simbolico. I collegamenti simbolici impediscono la creazione del modello. Inoltre, si consiglia di non includere file non necessari nel tarball.

Il container primario non ha superato i controllo dell'integrità del ping

Se il container primario non esegue i controlli di integrità del ping con il seguente messaggio di errore, indica che c'è un problema con il container o lo script:

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

Per risolvere questo problema, dovresti controllare i log dei CloudWatch log dell'endpoint in questione per vedere se ci sono errori o problemi che impediscono al contenitore di rispondere a o. /ping /invocations I log possono fornire un messaggio di errore che potrebbe indicare il problema. Dopo aver identificato l'errore e il motivo dell'errore, è necessario risolverlo.

È inoltre consigliabile testare la distribuzione del modello a livello locale prima di creare un endpoint.

• Utilizza la modalità locale SageMaker SDK per imitare l'ambiente ospitato distribuendo il modello su un endpoint locale. Per ulteriori informazioni, consulta Modalità locale.

• Usa i comandi vanilla docker per testare la risposta del container a /ping e /invocations. Per ulteriori informazioni, consulta local_test.