Das Problem war die Verbindung zu RabbitMQ. Da wir Live-Channels sortieren, hat die „Auto-Reconnect“-Funktion des RabbitMQ.Client viel Status über tote Channels gespeichert. Wir haben diese Konfiguration ausgeschaltet, da wir die "Vorteile" der Funktion "Auto-Reconnect" nicht benötigen und alles normal funktioniert. Es war mühsam, aber wir mussten im Grunde eine Windows-Bereitstellung einrichten und den üblichen Speicheranalyseprozess mit Windows-Tools (in diesem Fall Jetbrains dotMemory) durchführen. Die Verwendung von lldb ist überhaupt nicht produktiv.
Haftungsausschluss:Ich bin kein .NET Wizard.
Aber Sie sollten zwei Dinge tun, um mit den Best Practices von Kubernetes Schritt zu halten:
-
Definieren Sie sinnvolle Ressourcenlimits für Ihre App. Wenn die App nicht mehr als 200 MB Speicher benötigt, definieren Sie ein Ressourcenlimit, um zu verhindern, dass die App den gesamten verfügbaren Hostspeicher verbraucht. Beachten Sie jedoch, dass die Unix-API zum Abrufen von verfügbarem Speicher nicht in der Lage ist, die Kontrollgruppe des Prozesses zu verarbeiten, und immer den Hostspeicher ausgibt, egal was Ihre Kontrollgruppe sagt.
-
Sagen Sie Ihrer App, wie hoch dieses Ressourcenlimit ist. Es scheint, als hätte Ihre App nicht das Bedürfnis, Speicher freizugeben, da genügend vorhanden ist. Fast alle Anwendungen und auch Frameworks haben einen Schalter, um den maximal zu verbrauchenden Speicher festzulegen. Teilen Sie Ihrer App dieses Limit mit, und sie wird den Speicherdruck "sehen" und eine vollständige GC durchführen (was hier vermutlich das Problem sein könnte)