私のアプリケーションはいくつかのプロセスで構成されています。各プロセスには複数のスレッドがあります。
ヒープ・メモリー領域は、操作中に動的に割り当てられ、解放されます。
私のアプリケーションにメモリリークのバグがあり、それを修正しました。その後、旧正月連休中にエージングテストを実施しましたが、その結果、バグが完全に修正されたことを証明しました。
バーンインテスト中に、別の監視プロセスは定期的にアプリケーションプロセスの/ proc / PID / statmを読み取り、その値をファイルに書き込みます。
13日後、メモリログファイルを分析しました。
最初の 10 時間ほど常駐メモリ (RES) サイズが増加し続けます。
これは、glibcライブラリのメモリアロケータがシステムに「解放されたメモリ」を返さず、代わりに将来の再利用のために「アリーナ」にメモリフラグメントを保持するために予想される動作です。
その後、常駐メモリ（RES）サイズが上限に達し、10日間変更されていません。
これは、メモリリークのバグが修正されたことを意味します。長く生きる！
（修正前は制限に達せずに増え続けた。）
驚くべきことに、11日（約270時間）後、常駐メモリのサイズは急な角度（増加期間よりも急峻に）に減少し始め、「床」にぶつかり、火傷が終わるまで平らに保たれました。 - 期間中。
ほとんどのアプリケーションプロセスは同じ動作を示しています（一部はそうではありません）。
270時間経過すると、常駐メモリサイズが縮小し始めます。
このような減少の理由を説明できる人はいますか？
どんな仮説でも歓迎します。
「RESサイズの縮小に問題がありますか？」と質問できます。
削減自体は許可されていますが、私のアプリケーションの重要なプロセスとスレッドのタイミング速度の低下や一時的な一時停止を引き起こすようです。
「私が本当に欲しいもの」は、これらの速度低下や一時的な一時停止の原因を取り除き、プロセスとそのスレッドが遅延なく実行され続けることです。
環境情報：
オペレーティングシステム：Rocky Linuxバージョン8.8（Green Obsidian） CPU: Intel(R) Core(TM) i7-9850HE CPU @ 2.70GHz 言語: C++17 gccバージョン（dnf情報gcc）： 名前：湾岸協力協議会 バージョン: 8.5.0 リリース：18.el8 アーキテクチャ：x86_64 サイズ: 59M ソース: gcc-8.5.0-18.el8.src.rpm glibcバージョン（dnf情報glibc）： 名前: glibc バージョン: 2.28 バージョン: 225.el8 アーキテクチャ：x86_64 サイズ: 6.4M ソース: glibc-2.28-225.el8.src.rpm
私は2つの仮説を持っています。
1.
他のプロセス（アプリケーションプロセスではありません）に常駐メモリが割り当てられており、システム全体の総量が最大値を超えました。
アプリケーションプロセスは、解放された常駐メモリ領域を維持できず、「保存されたメモリ領域」をシステムに返し始めます。
13日目に「top」コマンドの結果を確認したところ、RESサイズが大幅に増加したプロセスは見つかりませんでした。
2.
Linuxまたはglibcメモリアロケータには、メモリスペースを自動的に切り捨てるための「ハウスキーピング」メカニズムがあります。
定期的に動作し、プロセスが解放されたメモリをシステムに返すように強制します。
私もオンラインで情報を確認しましたが、私が見つけた内容は次のようになり、私の「減少」の状況ではありませんでした。
デバッグを介してヒープメモリ管理の基本を理解しますが（それで「アリーナ」とは何かを理解します）、詳細はわかりません。