Aws-lambda-dotnet: Probleme mit dem Lambda-Speicherverbrauch

Vor kurzem haben wir eine Zunahme der ständig wachsenden Speichernutzung bestimmter Funktionen festgestellt, was zu Process exited before completing request und einer neuen Lambda-Instanz führte.

Wir haben dies zum ersten Mal am 11.09.2018 um 12:43:06 Uhr bemerkt. Kurz zuvor hatten wir eine Bereitstellung durchgeführt, bei der die Laufzeit von dotnetcore2.0 auf 2.1 geändert wurde. Es wurden keine weiteren wesentlichen Änderungen am Code vorgenommen, die einen Speicherverlust verursachen könnten, und er wurde vor dieser Bereitstellung fehlerfrei ausgeführt.

Ich habe den Fehler mit folgendem Code reproduziert:

public class DynamoDBTrigger
{
    private IAmazonDynamoDB _ddbClient;

    public DynamoDBTrigger()
    {
        _ddbClient = new AmazonDynamoDBClient();
    }

    [LambdaSerializer(typeof(Amazon.Lambda.Serialization.Json.JsonSerializer))]
    public void Process(DynamoDBEvent ev, ILambdaContext context)
    {
        foreach (var record in ev.Records)
        {
            var item = Convert(record.Dynamodb.NewImage);
            context.Logger.Log(JsonConvert.SerializeObject(item));                
        }
    }

    private Item Convert(Dictionary<string, AttributeValue> attributeMap)
    {
        using (var context = new DynamoDBContext(_ddbClient))
        {
            var doc = Document.FromAttributeMap(attributeMap);
            return context.FromDocument<Item>(doc, new DynamoDBOperationConfig { OverrideTableName = Environment.GetEnvironmentVariable("Table") });
        }
    }
}

Ich schreibe eine Zeile pro Sekunde in das auslösende Tablean und sehe eine Speichererhöhung von etwa 1 MB pro 3 Aufrufe, die dazu führt, dass es eine Weile bei 128 MB liegt, bevor ich dies protokolliere:

START RequestId: 3e5acba1-36fd-4a3a-bf84-659c5488437b Version: $LATEST
END RequestId: 3e5acba1-36fd-4a3a-bf84-659c5488437b
REPORT RequestId: 3e5acba1-36fd-4a3a-bf84-659c5488437b  Duration: 2293.32 ms    Billed Duration: 2300 ms Memory Size: 128 MB    Max Memory Used: 128 MB 
RequestId: 3e5acba1-36fd-4a3a-bf84-659c5488437b Process exited before completing request

Ich habe versucht, und das gleiche passiert mit einer 256-MB-Konfiguration, und der Anstieg scheint linear zu sein.

Ähnliches habe ich bei einem API-Gateway-Lambda-Proxy beobachtet, der den Einstiegspunkt ApiGatewayProxyFunction verwendet. In diesem Fall steigt der Speicher linear an, bis er die Grenze erreicht, an der er eine Weile verbleibt, bevor ASP.NET anscheinend Speicher löschen möchte:

Hervorheben von drei Beobachtungen:
1) hohe Dauer beim Aufruf vor und nach der Speicherbereinigung
2) Maximal verwendeter Speicher von 128 MB auf 68 MB gesunken
3) Derselbe verwendete Protokolldatenstrom, sodass die Lambda-Instanz nicht verworfen wird

Ich habe das Gefühl, dass wir nichts geändert oder neue Pakete hineingezogen haben. Könnte es möglich sein, dass die Veröffentlichung von .NET Core 2.1.4 ungefähr zur gleichen Zeit in der letzten Woche diese Verhaltensänderung verursacht hat?