Como posso resolver o erro de inferência do Amazon SageMaker “upstream atingiu o tempo limite” (110: A conexão atingiu o tempo limite) ao ler o cabeçalho de resposta do upstream”?
Quando eu implanto um endpoint do Amazon SageMaker ou executo um trabalho BatchTransform, a conexão atinge o tempo limite com um erro como este: “upstream atingiu o tempo limite (110: A conexão atingiu o tempo limite) ao ler o cabeçalho de resposta do upstream, cliente: 169.xxx.xxx.xxx, servidor:, solicitação: “POST /invocations HTTP/1.1”, upstream:“http://unix:/tmp/gunicorn.sock/invocations”, host: "169.xxx.xxx.xxx:8080"
Breve descrição
Esse erro indica um problema com a conexão entre o NGINX e o servidor Web. Esses dois componentes são executados no contêiner modelo, independentemente de você estar usando seu próprio contêiner ou um contêiner pré-criado. Esses componentes não estão diretamente relacionados à hospedagem do SageMaker ou às transformações em lote. No entanto, quando a conexão entre o NGINX e o servidor Web atinge o tempo limite, o SageMaker não consegue obter inferência do endpoint /invocations.
Para resolver esse problema:
- Reduza a latência do contêiner do algoritmo ou aumente o máximo de tempo limite do contêiner.
- Aumente as configurações de tempo limite do NGINX.conf.
Resolução
Reduza a latência do contêiner do algoritmo ou aumente o máximo de tempo limite
- **Se você estiver executando um código de inferência para serviços de hospedagem:**Seus contêineres modelo devem responder às solicitações em 60 segundos. O modelo em si pode ter um tempo máximo de processamento de 60 segundos. Se você sabe que seu modelo precisa de 50 a 60 segundos de tempo de processamento, defina o tempo limite do soquete SDK para 70 segundos. Para obter mais informações, consulte Como seu contêiner deve responder às solicitações de inferência.
- **Se você estiver executando um código de inferência para transformação em lote:**Use ModelClientConfig para configurar os parâmetros InvocationsTimeoutInSeconds e InvocationsMaxRetries.
O Amazon SageMaker define variáveis de ambiente especificadas em CreateModel e CreateTransformJob em seu contêiner. Ajuste os seguintes parâmetros da API para reduzir a latência do contêiner do algoritmo. Por exemplo, se a entrada for divisível, limite o tamanho da carga útil de cada solicitação definindo o campo MaxPayloadInMB ao criar uma tarefa de transformação.
- MaxPayloadInMB: o tamanho máximo da carga útil que é enviada ao contêiner. Se o contêiner puder processar rapidamente uma transformação em lote, aumente essa propriedade. Se a transformação em lote demorar mais do que o esperado, reduza essa propriedade.
- MaxConcurrentTransforms: o padrão é 1. Aumente essa configuração se você tiver mais de um operador NGINX.
- BatchStrategy: para ajustar o maior número possível de registros em um minilote (até o limite MaxPayloadInMB), defina BatchStrategy como MultiRecord e SplitType como Line.
Se você estiver usando um contêiner de framework SageMaker que implementa o Gunicorn, passe essas propriedades para o contêiner do Docker como variáveis de ambiente:
- SAGEMAKER _MODEL_SERVER_TIMEOUT: o tempo limite do servidor Gunicorn. Para liberar mais tempo para a solicitação ser processada antes do encerramento da conexão, aumente esse valor.
- SAGEMAKER _MODEL_SERVER_WORKERS: o número de operadores por CPU.
Aumente as configurações de tempo limite do NGINX.conf
Se você estiver usando um dos contêineres Docker pré-criados do Amazon SageMaker, não poderá modificar o arquivo NGINX.conf. Você pode modificar o NGINX.conf somente se estiver usando seu próprio contêiner do Docker.
Os tempos limite do NGINX podem causar falhas porque o Amazon SageMaker fecha a conexão após o tempo limite. Se o contêiner tentar ler ou gravar com a conexão fechada, a solicitação falhará. Modifique uma ou mais das propriedades a seguir para acomodar a sobrecarga da rede.
- proxy_read_timeout: essa é a quantidade de tempo que o NGINX espera por uma resposta do modelo após uma chamada request.send. Aumente esse valor para permitir que o Amazon SageMaker tenha mais tempo para processar a solicitação antes de fechar a conexão.
- worker_processes: esse é o número de threads de conexões de entrada. Na maioria dos casos, o valor deve ser igual ou maior que o número de núcleos da CPU. Por exemplo, para um tipo de instância de dois núcleos, como ml.m5.large, defina essa propriedade como no mínimo dois.
- worker_connections: esse é o número máximo de conexões simultâneas para cada processo de trabalho. Para isso, é recomendado definir o valor inicial como 1024.
Para obter mais informações sobre as configurações, consulte Módulo ngx_http_proxy_module na documentação do NGINX.
Conteúdo relevante
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há um ano