Problémem bylo připojení k RabbitMQ. Protože jsme používali kanály řazení živých kanálů, funkce "automatického opětovného připojení" RabbitMQ.Client udržovala hodně informací o mrtvých kanálech. Tuto konfiguraci jsme vypnuli, protože nepotřebujeme „výhody“ funkce „automatické opětovné připojení“ a vše začne fungovat normálně. Byla to bolest, ale v podstatě jsme museli nastavit nasazení Windows a provést obvyklý proces analýzy paměti pomocí nástrojů Windows (v tomto případě Jetbrains dotMemory). Používání lldb není vůbec produktivní.
Prohlášení:Nejsem žádný průvodce .NET.
Ale měli byste udělat dvě věci, abyste dodrželi osvědčené postupy Kubernetes:
-
Definujte rozumné limity zdrojů pro vaši aplikaci. Pokud aplikace nepotřebuje více než 200 MB paměti, definujte limit prostředků, aby aplikace nespotřebovala veškerou dostupnou paměť hostitele. Uvědomte si však, že unixové API pro získání dostupné paměti není schopno zpracovat cgroup, jakou má proces, a vždy vydává hostitelskou paměť bez ohledu na to, co vaše cgroup říká.
-
Sdělte své aplikaci, jaký je tento limit zdrojů. Zdá se, že vaše aplikace „necítí potřebu“ uvolnit paměť, protože je jí spousta. Téměř všechny aplikace a také frameworky mají přepínač pro definování maximální spotřebované paměti. Řekněte své aplikaci tento limit a ona „uvidí“ tlak v paměti a provede kompletní GC (což si myslím, že by zde mohl být problém)