Wie kann ich den Amazon SageMaker-Inferenzfehler „Upstream timed out“ (110) beheben: Verbindung (Timeout) beim Lesen des Antwort-Headers von Upstream“?

Kurzbeschreibung

Dieser Fehler weist auf ein Problem mit der Verbindung zwischen NGINX und dem Webserver hin. Beide Komponenten werden im Modellcontainer ausgeführt, unabhängig davon, ob Sie Ihren eigenen Container oder einen vorgefertigten Container verwenden. Diese Komponenten stehen nicht in direktem Zusammenhang mit SageMaker-Hosting oder Batch-Transformationen. Wenn die Verbindung zwischen NGINX und dem Webserver jedoch unterbrochen wird, kann SageMaker vom Endpunkt /invocations keine Rückschlüsse ziehen.

Um dieses Problem zu lösen:

1. Reduzieren Sie die Latenz des Algorithmus-Containers oder erhöhen Sie das Timeout-Limit des Containers.
2. Erhöhen Sie die Timeout-Einstellungen für Nginx.conf.

Lösung

Reduzieren Sie die Latenz des Algorithmus-Containers oder erhöhen Sie das Timeout-Limit

• Wenn Sie Inferenzcode für Hosting-Dienste ausführen: Ihre Modellcontainer müssen innerhalb von 60 Sekunden auf Anfragen antworten. Das Modell selbst kann eine maximale Verarbeitungszeit von 60 Sekunden haben. Wenn Sie wissen, dass Ihr Modell 50–60 Sekunden Verarbeitungszeit benötigt, setzen Sie das SDK-Socket-Timeout auf 70 Sekunden. Weitere Informationen finden Sie unter So sollte Ihr Container auf Inferenzanfragen reagieren.
• Wenn Sie Inferenzcode für die Batch-Transformation ausführen: Verwenden Sie ModelClientConfig, um die Parameter InvocationsTimeoutInSeconds und InvocationsMaxRetries zu konfigurieren.

Amazon SageMaker legt die in CreateModel und CreateTransformJob angegebenen Umgebungsvariablen für Ihren Container fest. Passen Sie die folgenden API-Parameter an, um die Latenz des Algorithmuscontainers zu reduzieren. Wenn die Eingabe beispielsweise aufteilbar ist, begrenzen Sie die Nutzlastgröße jeder Anforderung, indem Sie das Feld maxPayloadInMB festlegen, wenn Sie einen Transformationsjob erstellen.

• Maximale Nutzlast in MB: Die maximale Größe der Nutzlast, die an den Container gesendet wird. Wenn der Container eine Batch-Transformation schnell verarbeiten kann, erhöhen Sie diese Eigenschaft. Wenn die Batch-Transformation länger als erwartet dauert, reduzieren Sie diese Eigenschaft.
• Max. Anzahl gleichzeitiger Transformationen: Die Standardeinstellung ist 1. Erhöhen Sie diese Einstellung, wenn Sie mehr als einen NGINX-Worker haben.
• Batch-Strategie: Um so viele Datensätze wie möglich in einen Mini-Batch aufzunehmen (bis zum MaxPayloadInMB-Limit), setzen Sie BatchStrategy auf MultiRecord und SplitType auf Line.

Wenn Sie einen SageMaker-Framework-Container verwenden, der Gunicorn implementiert, übergeben Sie diese Eigenschaften als Umgebungsvariablen an den Docker-Container:

• SAGEMAKER _MODEL_SERVER_TIMEOUT: Das Timeout für den Gunicorn-Server. Erhöhen Sie diesen Wert, um mehr Zeit für die Bearbeitung der Anfrage zu haben, bevor die Verbindung geschlossen wird.
• SAGEMAKER _MODEL_SERVER_WORKERS: Die Anzahl der Arbeiter pro CPU.

Erhöhen Sie die Timeout-Einstellungen für Nginx.conf

Wenn Sie einen der vorgefertigten Docker-Container von Amazon SageMaker verwenden, können Sie die Datei Nginx.conf nicht ändern. Sie können Nginx.conf nur ändern, wenn Sie Ihren eigenen Docker-Container verwenden.

NGINX-Timeouts können zu Fehlern führen, da Amazon SageMaker die Verbindung nach dem Timeout schließt. Wenn Ihr Container versucht, von der geschlossenen Verbindung zu lesen oder in sie zu schreiben, schlägt die Anfrage fehl. Ändern Sie eine oder mehrere der folgenden Eigenschaften, um den Netzwerk-Overhead zu berücksichtigen.

• proxy_read_timeout: Dies ist die Zeit, die NGINX nach einem request.send-Aufruf auf eine Antwort des Modells wartet. Erhöhen Sie diesen Wert, damit Amazon SageMaker mehr Zeit hat, die Anfrage zu verarbeiten, bevor die Verbindung geschlossen wird.
• worker_processes: Dies ist die Anzahl der Threads für eingehende Verbindungen. In den meisten Fällen sollte der Wert gleich oder größer als die Anzahl der CPU-Kerne sein. Setzen Sie diese Eigenschaft beispielsweise für einen Instance-Typ mit zwei Kernen wie ml.m5.large auf mindestens zwei.
• worker_connections: Dies ist die maximale Anzahl gleichzeitiger Verbindungen für jeden Arbeitsprozess. Es hat sich bewährt, den Startwert dafür auf 1024 festzulegen.

Weitere Informationen zu den Konfigurationseinstellungen finden Sie unter Modul ngx_http_proxy_module in der NGINX-Dokumentation.