問題は、RabbitMQ への接続でした。ライブ チャネルの並べ替えを使用していたため、RabbitMQ.Client の「自動再接続」機能は、デッド チャネルに関する多くの状態を保持していました。 「自動再接続」機能の「特典」は必要なく、すべてが正常に機能し始めるため、この構成をオフにしました。面倒でしたが、基本的に Windows デプロイをセットアップし、Windows ツール (この場合は Jetbrains dotMemory) を使用して通常のメモリ分析プロセスを実行する必要がありました。 lldb の使用はまったく生産的ではありません。
免責事項:私は .NET ウィザードではありません。
ただし、Kubernetes のベスト プラクティスに合わせて次の 2 つのことを行う必要があります。
<オール>アプリの適切なリソース制限を定義します。アプリが 200MB を超えるメモリを必要としない場合は、リソース制限を定義して、アプリが使用可能なホスト メモリをすべて消費しないようにします。ただし、使用可能なメモリを取得するための Unix API は、プロセスが持つ cgroup を処理することができず、cgroup が何を言おうと、常にホスト メモリを出力することに注意してください。
このリソース制限をアプリに伝えます。十分なメモリがあるため、アプリはメモリを解放する「必要性を感じていない」ようです。ほとんどすべてのアプリケーションとフレームワークには、消費する最大メモリを定義するスイッチがあります。アプリにこの制限を伝えると、アプリはメモリ不足を「認識」し、完全な GC を実行します (ここで問題になる可能性があると思います)