Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Python-Laufzeit für verwaltete Lambda-Instanzen
<a name="lambda-managed-instances-python-runtime"></a>

Die Lambda-Laufzeit verwendet mehrere Python-Prozesse, um gleichzeitige Anfragen zu verarbeiten. Jede gleichzeitige Anforderung wird in einem separaten Prozess mit eigenem Speicherplatz und eigener Initialisierung ausgeführt. Jeder Prozess verarbeitet synchron jeweils eine Anfrage. Prozesse teilen sich den Speicher nicht direkt, sodass globale Variablen, Caches auf Modulebene und Singleton-Objekte zwischen gleichzeitigen Anfragen isoliert werden.

## Konfiguration der Parallelität
<a name="lambda-managed-instances-python-concurrency-config"></a>

Die maximale Anzahl gleichzeitiger Anfragen, die Lambda an jede Ausführungsumgebung sendet, wird durch die `PerExecutionEnvironmentMaxConcurrency` Einstellung in der Funktionskonfiguration gesteuert. Dies ist eine optionale Einstellung, und der Standardwert variiert je nach Laufzeit. Für Python-Laufzeiten ist die Standardeinstellung 16 gleichzeitige Anfragen pro vCPU, oder Sie können Ihren eigenen Wert konfigurieren. Dieser Wert bestimmt auch die Anzahl der Prozesse, die von der Python-Laufzeit verwendet werden. Lambda passt die Anzahl der gleichzeitigen Anfragen automatisch bis zum konfigurierten Maximum an, basierend auf der Kapazität jeder Ausführungsumgebung, um diese Anfragen aufzunehmen.

**Wichtig**  
Die Verwendung prozessbasierter Parallelität bedeutet, dass jeder Runtime-Worker-Prozess seine eigene Initialisierung durchführt. Die gesamte Speicherbelegung entspricht dem Arbeitsspeicher pro Prozess multipliziert mit der Anzahl gleichzeitiger Prozesse. Wenn Sie große Bibliotheken oder Datensätze laden und über eine hohe Parallelität verfügen, haben Sie einen großen Speicherbedarf. Je nach Arbeitslast müssen Sie möglicherweise Ihr CPU-to-memory Verhältnis anpassen oder eine niedrigere Parallelitätseinstellung verwenden, um eine Überschreitung des verfügbaren Speichers zu vermeiden. Sie können die `MemoryUtilization` Metrik verwenden CloudWatch , um den Speicherverbrauch zu verfolgen.

## Erstellung von Funktionen für mehrere Parallelitäten
<a name="lambda-managed-instances-python-building"></a>

Aufgrund des prozessbasierten Multi-Concurrency-Modells greifen Lambda Managed Instances-Funktionen, die Python-Laufzeiten verwenden, bei mehreren Aufrufen nicht gleichzeitig auf speicherinterne Ressourcen zu. Sie müssen keine Programmierpraktiken anwenden, um die Sicherheit der Parallelität im Speicher zu gewährleisten.

## Gemeinsames /tmp-Verzeichnis
<a name="lambda-managed-instances-python-shared-tmp"></a>

Das `/tmp` Verzeichnis wird von allen gleichzeitigen Anfragen in der Ausführungsumgebung gemeinsam genutzt. Gleichzeitige Schreibvorgänge in dieselbe Datei können zu Datenbeschädigungen führen, z. B. wenn ein anderer Prozess die Datei überschreibt. Um dieses Problem zu lösen, implementieren Sie entweder Dateisperren für gemeinsam genutzte Dateien oder verwenden Sie eindeutige Dateinamen pro Prozess oder pro Anfrage, um Konflikte zu vermeiden. Denken Sie daran, nicht benötigte Dateien zu bereinigen, um zu vermeiden, dass der verfügbare Speicherplatz aufgebraucht wird.

## Protokollierung
<a name="lambda-managed-instances-python-logging"></a>

Das Verschachteln von Protokollen (Protokolleinträge verschiedener Anfragen werden in Protokollen verschachtelt) ist bei Systemen mit mehreren gleichzeitigen Vorgängen normal.

Funktionen, die Lambda Managed Instances verwenden, verwenden immer das strukturierte JSON-Protokollformat, das mit [erweiterten Protokollierungssteuerungen](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) eingeführt wurde. Dieses Format beinhaltet die`requestId`, sodass Protokolleinträge einer einzelnen Anfrage zugeordnet werden können. Wenn Sie das `logging` Modul aus der Python-Standardbibliothek in Lambda verwenden, `requestId` ist das automatisch in jedem Protokolleintrag enthalten. Weitere Informationen finden Sie unter [Erweiterte Lambda-Protokollierungssteuerelemente mit Python verwenden](https://docs.aws.amazon.com/lambda/latest/dg/python-logging.html#python-logging-advanced).

## Kontext anfordern
<a name="lambda-managed-instances-python-request-context"></a>

Wird verwendet`context.aws_request_id`, um auf die Anforderungs-ID für die aktuelle Anfrage zuzugreifen.

Bei Python-Laufzeiten können Sie die `_X_AMZN_TRACE_ID` Umgebungsvariable verwenden, um mit Lambda Managed Instances auf die X-Ray Trace-ID zuzugreifen. Die X-Ray Trace-ID wird bei Verwendung des SDK automatisch weitergegeben. AWS 

Wird verwendet`context.get_remaining_time_in_millis()`, um Timeouts zu erkennen. Weitere Informationen finden Sie unter [Fehlerbehandlung und Wiederherstellung](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).

**Beispiel: Behandlung von Timeouts**

Prüfen Sie die verbleibende Zeit vor jeder Arbeitseinheit und beenden Sie die Verarbeitung, bevor das Timeout ausgelöst wird. Die Konfiguration `BUFFER_MS` erfolgt auf der Grundlage der voraussichtlichen Dauer Ihres nächsten Arbeitsabschnitts.

```
BUFFER_MS = 2000  # Configure based on your next chunk of work

def handler(event, context):
    for item in event["items"]:
        if context.get_remaining_time_in_millis() < BUFFER_MS:
            return {"statusCode": 206, "body": "Timeout approaching, stopping early"}
        process_item(item)
    return {"statusCode": 200, "body": "Done"}
```

**Beispiel: Weitergabe von Terminen an nachgelagerte Anrufe**

Wenn Sie Anrufe an nachgelagerte Dienste tätigen, geben Sie die verbleibende Zeit als Timeout an, um zu vermeiden, dass Sie an Netzwerkanrufen hängen bleiben, die Ihren Aufruf überdauern würden. Das boto3 SDK unterstützt keine Timeouts pro Anfrage auf einem vorhandenen Client. Sie müssen also einen Client mit dem gewünschten Timeout erstellen. Prüfen Sie für Funktionen mit hohem Durchsatz, ob ein bei der Initialisierung konfiguriertes festes Timeout besser geeignet ist als die Erstellung eines Clients pro Anfrage.

```
import boto3
from botocore.config import Config

def handler(event, context):
    remaining = context.get_remaining_time_in_millis() / 1000
    timeout = max(1, remaining - 0.5)
    s3 = boto3.client("s3", config=Config(read_timeout=timeout, connect_timeout=timeout))
    response = s3.get_object(Bucket="my-bucket", Key="my-key")
    return {"statusCode": 200, "body": "Done"}
```

## Initialisierung und Herunterfahren
<a name="lambda-managed-instances-python-init-shutdown"></a>

Die Initialisierung der Funktion erfolgt einmal pro Prozess. Möglicherweise werden Protokolleinträge wiederholt, wenn Ihre Funktion während der Initialisierung Protokolle ausgibt.

Bei Lambda-Funktionen mit Erweiterungen gibt die Ausführungsumgebung beim Herunterfahren ein SIGTERM-Signal aus. Dieses Signal wird von Erweiterungen verwendet, um Bereinigungsaufgaben wie das Leeren von Puffern auszulösen. Sie können SIGTERM-Ereignisse abonnieren, um Aufgaben zur Funktionsbereinigung auszulösen, z. B. das Schließen von Datenbankverbindungen. Weitere Informationen zum Lebenszyklus der Ausführungsumgebung finden Sie unter [Verständnis des Lebenszyklus der Lambda-Ausführungsumgebung](lambda-runtime-environment.md).

## Versionen von Abhängigkeiten
<a name="lambda-managed-instances-python-dependencies"></a>

Lambda Managed Instances erfordert die folgenden Mindestpaketversionen:
+ Powertools für AWS Lambda (Python): Version 3.23.0 oder höher

## Powertools für AWS Lambda (Python)
<a name="lambda-managed-instances-python-powertools"></a>

Powertools for AWS Lambda (Python) ist mit Lambda Managed Instances kompatibel und bietet Dienstprogramme für Logging, Tracing, Metriken und mehr. Weitere Informationen finden Sie unter [Powertools for AWS Lambda (Python)](https://github.com/aws-powertools/powertools-lambda-python).

## Nächste Schritte
<a name="lambda-managed-instances-python-next-steps"></a>
+ Überprüfen Sie die [Java-Laufzeit für Lambda Managed Instances](lambda-managed-instances-java-runtime.md)
+ [Node.js Laufzeit für Lambda Managed Instances](lambda-managed-instances-nodejs-runtime.md) überprüfen
+ [.NET-Laufzeit für Lambda Managed Instances](lambda-managed-instances-dotnet-runtime.md) überprüfen
+ Erfahren Sie mehr über die [Skalierung von Lambda Managed Instances](lambda-managed-instances-scaling.md)