0

私は無期限に成長する内部 C++ アプリケーションを持っています。そのため、RSS が特定のピーク サイズ (2.0G) に達すると実際にアプリケーションを強制終了するロジックを実装して、順序の類似性を維持する必要がありました。ただし、これはいくつかの奇妙な動作を示しています。

まず、Valgrind と memcheck を使用してアプリケーションを実行し、ランダムなメモリ リークをあちこちで修正しました。ただし、これらのメモリ リークの程度は、数十メガバイト単位で測定されました。これは理にかなっています。実際のメモリ リークはなく、アプリケーション側のメモリ管理が不十分である可能性があるからです。

次に、Valgrind と Massif を使用して、メモリがどこに向かっているのかを確認しました。ピークのスナップショットは 161M で、RSS フィールドを使用して確認できる 1.9G+ のピークにはほど遠いものです。最大の消費は、std::string であると予想される場所ですが、これは異常ではありません。

最後に、これが最も不可解です。このメモリ リークに気付く前に、AWS でこのサービスを実際にテストしていたのですが、楽しみのために、CC2.8XL マシンでワーカーの数を 44 に設定しました。労働者。これは 60.5G の RAM で、スワップはありません。1 か月早送りします。私はホストを見に行きます-そして、低いと見よ、それは RAM で限界に達しています--しかし! プロセスはまだ正常に実行されており、メモリ使用量のさまざまな段階でスタックしています。800M から 1.9G までほぼ均等に分散されています。ときどきdmesg、メモリを割り当てることができないという Xen エラーが出力されますが、それ以外は、プロセスが終了することはなく、アクティブに処理を続けます (つまり、「スタック」していません)。

私がここに欠けているものはありますか？基本的には機能していますが、私の人生では、その理由がわかりません。次に何を探すべきかについて、何をお勧めしますか? それを理解するのに役立つツールはありますか?

4

1 に答える 1

1

valgrind memcheck は、メモリを「放棄」したときにのみ検出されることに注意してください。while(1) vec.push_back(n++);使用可能なすべてのメモリがいっぱいになりますが、リークは報告されません。物事の音によって、あなたは多くのスペースを占める弦をどこかに集めています。私はまた、多くのメモリを使用するが実際にはリークしていないコードにも取り組んできました [valgrind が満足しているのがリークではないのは、さまざまな場所にあります!]。メモリ割り当てにいくつかのマーカーを追加するなどして、メモリを割り当てている場所を示すだけで、追跡できる場合があります。

関数にstd::は通常、Allocator引数があります。いくつかの異なるメモリ プールを実装すると、メモリを割り当てている場所がわかる場合があります。

プロセスがメモリを断片化していると思われるケースも見たので、ヒープに小さな空き領域がたくさんあります。これは、たとえば、ストリング。

于 2014-03-19T19:01:56.273 に答える