Come posso risolvere l'errore di inferenza di Amazon SageMaker "upstream timed out (110: Connection timed out) while reading response header from upstream"?

4 minuti di lettura
0

Quando distribuisco un endpoint Amazon SageMaker o eseguo un processo BatchTransform, la connessione si interrompe con un errore simile al seguente: "upstream timed out (110: Connection timed out) while reading response header from upstream, client: 169.xxx.xxx.xxx, server: , request: "POST /invocations HTTP/1.1", upstream: "http://unix:/tmp/gunicorn.sock/invocations" , host: "169.xxx.xxx.xxx:8080"

Breve descrizione

Questo errore indica un problema con la connessione tra NGINX e il server Web. Entrambi questi componenti vengono eseguiti nel container del modello, indipendentemente dal fatto che stia utilizzando il tuo container o uno predefinito. Questi componenti non sono direttamente correlati all'hosting di SageMaker o alle trasformazioni in batch. Tuttavia, quando la connessione tra NGINX e il server Web scade, SageMaker non può ottenere inferenze dall'endpoint /invocations.

Per risolvere questo problema:

  1. Riduci la latenza del container dell'algoritmo o aumenta il limite di timeout del container.
  2. Aumenta le impostazioni di timeout di NGINX.conf.

Risoluzione

Riduzione della latenza del container dell'algoritmo o aumento del limite di timeout

  • Se stai eseguendo codice di inferenza per i servizi di hosting: i container del modello devono rispondere alle richieste entro 60 secondi. Il modello stesso può avere un tempo di elaborazione massimo di 60 secondi. Se sai che il tuo modello richiede 50-60 secondi per l'elaborazione, imposta il timeout del socket SDK su 70 secondi. Per ulteriori informazioni, consulta How your container should respond to inference requests.
  • Se stai eseguendo codice di inferenza per la trasformazione in batch: utilizza ModelClientConfig per configurare i parametri InvocationsTimeoutInSeconds e InvocationsMaxRetries.

Amazon SageMaker imposta le variabili di ambiente specificate in CreateModel e CreateTransformJob sul tuo container. Regola i seguenti parametri API per ridurre la latenza del container dell'algoritmo. Ad esempio, se l'input è divisibile, limita la dimensione del payload di ogni richiesta impostando il campo MaxPayloadInMB quando crei un processo di trasformazione.

  • MaxPayloadInMB: la dimensione massima del payload inviato al container. Se il container è in grado di elaborare rapidamente una trasformazione in batch, aumenta questa proprietà. Se la trasformazione in batch richiede più tempo del previsto, riduci questa proprietà.
  • MaxConcurrentTransforms: l'impostazione predefinita è 1. Aumenta questa impostazione se hai più di un worker NGINX.
  • **BatchStrategy:**Per inserire il maggior numero possibile di record in un mini-batch (fino al limite MaxPayloadInMB), imposta BatchStrategy su MultiRecord e SplitType su Line.

Se stai utilizzando un container del framework SageMaker che implementa Gunicorn, passa queste proprietà al container Docker come variabili di ambiente:

  • SAGEMAKER _MODEL_SERVER_TIMEOUT: il timeout per il server Gunicorn. Per concedere più tempo all'elaborazione della richiesta prima della chiusura della connessione, aumenta questo valore.
  • SAGEMAKER _MODEL_SERVER_WORKERS: il numero di worker per CPU.

Aumento delle impostazioni di timeout di NGINX.conf

Se utilizzi uno dei container Docker predefiniti di Amazon SageMaker, non puoi modificare il file NGINX.conf. Puoi modificare NGINX.conf solo se utilizzi il tuo container Docker.

I timeout NGINX possono causare errori poiché Amazon SageMaker chiude la connessione dopo il timeout. Se il container tenta di leggere o scrivere sulla connessione chiusa, la richiesta ha esito negativo. Modifica una o più delle seguenti proprietà per far fronte al sovraccarico della rete.

  • proxy_read_timeout: questa è la quantità di tempo in cui NGINX attende una risposta dal modello dopo una chiamata request.send. Aumenta questo valore per concedere più tempo ad Amazon SageMaker per elaborare la richiesta prima della chiusura della connessione.
  • worker_processes: questo è il numero di thread per le connessioni in entrata. Nella maggior parte dei casi, il valore deve essere uguale o superiore al numero di core della CPU. Ad esempio, per un tipo di istanza a due core come ml.m5.large, imposta questa proprietà su un minimo di due.
  • worker_connections: questo è il numero massimo di connessioni simultanee per ogni processo worker. È consigliabile impostare il valore iniziale su 1.024.

Per ulteriori informazioni sulle impostazioni di configurazione, consulta Module ngx_http_proxy_module nella documentazione di NGINX.


AWS UFFICIALE
AWS UFFICIALEAggiornata 2 anni fa