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 contagem de CPUs ativas

Se você implantar um SageMaker modelo com uma máquina virtual Linux Java (JVM), poderá encontrar erros de detecção que impedem o uso dos recursos de CPU disponíveis. Esse problema afeta algumas JVMs compatíveis com Java 8 e Java 9, e a maioria das compatíveis com Java 10 e Java 11. Essas JVMs implementam um mecanismo que detecta e manipula a contagem de CPU 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 que a JVM usa para gerenciar esses recursos. Atualmente, isso faz com que o contêiner detecte incorretamente o número de CPUs disponíveis.

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

Para obter um exemplo de detecção incorreta, em um contêiner configurado para SageMaker ser implantado com uma JVM baseada em Java8_191 e que tenha quatro CPUs disponíveis na instância, execute o seguinte comando para iniciar sua 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)

Muitas das JVMs afetadas por esse problema têm uma opção para desabilitar esse comportamento e restabelecer acesso total a todas as CPUs na instância. Desabilite o comportamento indesejado e estabeleça o acesso total a todas as CPUs da instância incluindo o parâmetro -XX:-UseContainerSupport ao iniciar aplicativos Java. Por exemplo, execute o comando java para iniciar a JVM da 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 a JVM usada em seu contêiner é compatível com o parâmetro -XX:-UseContainerSupport. Se for compatível, sempre passe o parâmetro ao iniciar a JVM. Isso fornece acesso a todas as CPUs em suas instâncias.

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

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.