ソフトウェアのメモリ消費量が多い問題を分析しています。この高いメモリ消費量に対応するコア ファイルがあります (このコア ファイルは、コア ファイルを生成するアプリケーションを強制終了することによって生成されます)。しかし、このコア ファイルを使用して実際のメモリ消費量を表示することはできません。Totalview と gdb を使用しました...これら 2 つを使用すると、プロセスによって消費される合計メモリのスナップショットを取得できず、どのライブラリがすべてのメモリを消費していますか。
このメモリ消費量は 10 日から 20 日以上にわたって発生しているため、このメモリ消費量が多い原因を突き止めようとしています。
valgrind は、このコア ファイルの分析に役立ちますか?
入力/提案は大歓迎です。
@suresh、
こんにちは、私は Rogue Wave Software の TotalView のプロダクト マネージャーです。
シナリオについてもう少し説明していただけますか？プログラムが「通常のメモリ消費量」で長時間実行されていて、突然メモリ消費量が急増していませんか? それとも、利用可能なリソースを使い果たすまで、プログラムはゆっくりと着実にメモリを消費していますか?
クラッシュしているときは、文字通りメモリが不足しているためにクラッシュしているのでしょうか、それともスワッピングを開始して応答しなくなったためにクラッシュしているのでしょうか?
一般に、MemoryScape で (TotalView またはスタンドアロン バージョンで) 実行することをお勧めします。予期しないメモリ消費が見られるようになったら、一時停止してメモリ リーク レポートを実行することをお勧めします。これは問題を正しく示している可能性があります。
データを参照するポインターがまだあるため、メモリの使用が「古典的な」リークではない可能性がありますが、単に過剰に割り当てているだけです。この場合、リーク レポートには何も表示されませんが、どの割り当てが増加しているかを監視することで、どの割り当てが「悪くなった」かを特定できる場合があります。これを行うにはいくつかの方法があります。
定期的に一時停止し、ヒープ ステータス ソース コード レポートでヒープ使用量がどのように分類されるかを確認します。たとえば、特定のソース コード ファイルに関連付けられている割り当ての数が増え続けていることに気付くかもしれません。
TotalView を使用している場合は、プログラムが正常に動作しているように見えるときに「ヒープ ベースラインの設定」機能を使用してから、このベースラインに対してフィルター処理を行うことができます。ここでも、ソース コード レポートを使用することをお勧めします (ただし、グラフィカル レポートまたはバックトレース レポートもフィルタリングをサポートしています)。
または、「メモリ データのエクスポート」機能を使用して、「通常の」ヒープ ステータスのイメージを保存することもできます。これにより、バイナリ ヒープ ステータス ファイルが作成されます。次に、プログラムのメモリ消費量が多い状態になるまでプログラムを実行します。その時点でライブ アプリを一時停止し、保存されたヒープ データ ファイルをロードすると、比較を行うことができます。
うーん、長くなってきた。最後に 1 つの考え。あなたはコアファイルを取得していると言いました。デバッガーの下で、クリーンアップされる前に実行中のプログラムを調べる機会が得られるはずです。これが起こらない場合は、私に知らせてください。本当にコア ファイルを介して作業したい場合 (たとえば、これが実稼働環境で発生していて、そこでデバッガを実行したくない場合)、お知らせください。HIA を使用してアプリケーションをインストルメント化できる手法があります。次に、ヒープ ステータスのオフライン分析を実行できるようにします。
幸運を！
クリス・ゴットブラス
Rogue Wave Software、TotalView および ThreadSpotter のプリンシパル プロダクト マネージャー
電子メール: 最初に。最後はローグウェイブで。コム