As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Solucione problemas de implantação de SageMaker modelos da Amazon

Se você encontrar algum problema ao implantar modelos de aprendizado de máquina na Amazon SageMaker, consulte as orientações a seguir.

Erros de detecção na CPU contagem ativa

Se você implantar um SageMaker modelo com uma máquina virtual Linux Java (JVM), poderá encontrar erros de detecção que impedem o uso CPU dos recursos disponíveis. Esse problema afeta alguns JVMs que suportam Java 8 e Java 9, e a maioria que suporta Java 10 e Java 11. Eles JVMs implementam um mecanismo que detecta e manipula a CPU contagem e a memória máxima disponível ao executar um modelo em um contêiner Docker e, de forma mais geral, nos taskset comandos ou grupos de controle do Linux (cgroups). SageMakeras implantações aproveitam algumas das configurações JVM usadas para gerenciar esses recursos. Atualmente, isso faz com que o contêiner detecte incorretamente o número de disponíveisCPUs.

SageMaker não limita o acesso CPUs a uma instância. No entanto, eles JVM podem detectar a CPU contagem 1 quando CPUs houver mais disponíveis para o contêiner. Como resultado, o JVM ajusta todas as suas configurações internas para serem executadas como se apenas o 1 CPU núcleo estivesse disponível. Essas configurações afetam a coleta de lixo, os bloqueios, os encadeamentos do compilador e outros JVM componentes internos que afetam negativamente a simultaneidade, a taxa de transferência e a latência do contêiner.

Para ver um exemplo de detecção incorreta, em um contêiner configurado para SageMaker que seja implantado com um JVM baseado em Java8_191 e que tenha quatro disponíveis CPUs na instância, execute o seguinte comando para iniciar seu: JVM

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

Isso gera a saída a seguir:

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)

Muitos dos JVMs afetados por esse problema têm a opção de desativar esse comportamento e restabelecer o acesso total a todos os CPUs da instância. Desative o comportamento indesejado e estabeleça acesso total a todas as instâncias CPUs incluindo o -XX:-UseContainerSupport parâmetro ao iniciar aplicativos Java. Por exemplo, execute o java comando para iniciar o seu da JVM seguinte forma:

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

Isso gera a saída a seguir:

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)

Verifique se o JVM usado em seu contêiner suporta o -XX:-UseContainerSupport parâmetro. Se isso acontecer, sempre passe o parâmetro ao iniciar seuJVM. Isso fornece acesso a todos os CPUs em suas instâncias.

Você também pode encontrar esse problema ao usar indiretamente um JVM em SageMaker contêineres. Por exemplo, ao usar um JVM para oferecer suporte ao SparkML Scala. O -XX:-UseContainerSupport parâmetro também afeta a saída retornada pelo Java Runtime.getRuntime().availableProcessors() API.

Problemas com a implantação de um arquivo model.tar.gz

Quando você implanta um modelo usando um arquivo model.tar.gz, o tarball do modelo não deve incluir nenhum link simbólico. Os links simbólicos fazem com que a criação do modelo falhe. Além disso, recomendamos que você não inclua arquivos desnecessários no pacote.

O contêiner primário não passou nas verificações de integridade do ping

Se seu contêiner primário falhar nas verificações de integridade do ping com a seguinte mensagem de erro, isso indica que há um problema com seu contêiner ou script:

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

Para solucionar esse problema, você deve verificar os CloudWatch registros de registros do endpoint em questão para ver se há algum erro ou problema que esteja impedindo o contêiner de responder a ou. /ping /invocations Os logs podem fornecer uma mensagem de erro que pode apontar para o problema. Depois de identificar o erro e o motivo da falha, você deve resolvê-lo.

Também é uma boa prática testar a implantação do modelo localmente antes de criar um endpoint.