問題タブ [massif]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
ubuntu - valgrind massif ヒープ プロファイラには詳細なスナップショット ビューはありません - どのようにズームイン/ズームアウトしますか?
そのため、Ubuntu 18 で C++ プログラムのヒープ メモリ使用量を確認しようとしています。
私はそれを使用して実行しました:
valgrind --tool=massif --smc-check=all ./myprogram
かなり大きな出力が得られますが、問題ありません。Massif-visualizer を使用して表示します。
私はかなりのグラフを取得します。しかし、プログラムの最後を詳しく調べて、どの程度シャットダウンするかを確認したいと思います。しかし、グラフ ビューを拡大できないようで、これを行うオプションがありません。
マンページ(ここ)には次のように書かれています:
Massif は、本質的にツリーを構成するいくつかの詳細なスナップショットを生成します。単純なツリー ビューよりも快適な方法で概要を把握したい場合は、詳細なスナップショット タブに切り替えて、コール グラフとして視覚化されたツリーを参照してください。ズームイン、ズームアウト、鳥瞰図を使用して、特定のスナップショットに何が寄与しているかを確認します。同じメモリ コストの関数呼び出しは、興味深い部分を簡単に見つけられるようにグループ化されていることに注意してください。
しかし、" " のオプションが表示されswitch over to the detailed snapshot tabません... 他の誰かがそれを行う方法を知っていますか?
Ubuntu 18
Massif-ビジュアライザー 0.7
c++ - Linux 仮想メモリの理解: valgrind の massif 出力は、--pages-as-heap の有無で大きな違いを示しています
このパラメーターに関するドキュメントを読みましたが、その違いは本当に大きいです! 有効にすると、単純なプログラム (以下を参照) のメモリ使用量は約7 GBになり、無効にすると、報告される使用量は約160 KBになります。
topまた、約 7 GB も表示されます。これは、結果をpages-as-heap=yes.
(私には理論がありますが、それがそのような大きな違いを説明するとは思わないので、助けを求めてください)。
特に気になるのは、報告されたメモリ使用量のほとんどが によって使用されstd::string、what?が印刷されることはありません (つまり、実際の容量はかなり小さいということです)。
アプリのプロファイリング中に使用する必要がありますpages-as-heap=yes。「誤検知」を回避する方法が気になります
コード スニペット:
以下でコンパイル:g++ --std=c++11 -fno-inline -g3 -pthread
とpages-as-heap=yes:
としながらpages-as-heap=no:
スレッドのくだらない処理は無視してください。これは非常に短い例です。
アップデート
これはまったく関係がないstd::stringようです。@Lawrence が示唆したように、これintはヒープにシングルを割り当てるだけで再現できます (with new)。@Lawrence は、彼のコメントを引用して、ここでの本当の答えに非常に近いと思います (より詳しい読者にとっては簡単です)。
ローレンス:
@KirilKirov文字列の割り当ては実際にはそれほど多くのスペースを占めていません...各スレッドは初期スタックを取得し、ヒープアクセスは不正確に反映される大量のスペース(約70m)をマップします。1 つの文字列を宣言してからスピン ループを作成するだけで測定できます...同じ仮想メモリの使用量が示されています – Lawrence 9 月 28 日 14:51
自分:
@Lawrence - その通りです!OK、つまり、各スレッドで、最初のヒープ割り当てで、メモリマネージャー(またはOSなど)がスレッドのヒープに大量のメモリを専用に割り当てていると言っています(そして、このように見えます)。ニーズ?そして、このチャンクは後で再利用されますか (または、必要に応じて縮小されますか)? – キリル キーロフ 9 月 28 日 15:45
ローレンス:
@KirilKirovその性質の何か...正確な割り当ては、おそらくmallocの実装などに依存します–ローレンス2日前
c++ - このデーモンで仮想メモリのフット プリントが継続的に増加する理由を確認するにはどうすればよいですか?
Cassandra データベースへのプロキシとして使用するデーモンを作成しました。snapdbproxy他のサーバーやツールから CQL コマンドをプロキシするので、私はそれを呼び出します。
そのツールにアクセスすると、新しいスレッドが作成され、さまざまな CQL コマンドが管理されます。接続が失われると、スレッドを正常に終了します。
メモリ フットプリントを見ると、非常に急速に増加します (最もアクティブなシステムは仮想メモリの Gb にすぐに到達し、常に増加するスワップ メモリを使用します)。起動時には、約 300Mb です。
このソフトウェアは、デストラクタ、RAII、スマート ポインタなどを使用して C++ で記述されていますが、次のことを確認しました。
(私は Linux で g++ を使用して
-fsanitizer=addressいます)、リークはありません(OpenSSL によって作成されたいくつかの Cryto バッファを取り除く方法が見つからないため、300 バイト未満の非常に少数です)。valgrind massif では、初期化時に 4.7mB を使用し、その後は 4mB 未満を使用しています (同じコードを 1 時間以上実行しても同じ結果が得られました!)
ms_print(スタックはすべてゼロなので、スタックを削除しました)の出力がいくつかあります。
ご覧のとおり、1 時間後に他のさまざまなデーモンから多数のアクセス (少なくとも 100 回のアクセス) が行われた後、valgrind は、約 4mB のメモリしか使用していないことを示しています。最初の試みはおそらく失敗しただろうと思い、2 回試みました。同じ結果です。
だから...私は多かれ少なかれアイデアがありません。-fsanitizer=addressmassifの出力で示されているように、各スレッドの終了時にすべてが正しく解放され、プロセス全体が解放されているにもかかわらず、仮想メモリの観点からプロセスが増加し続けるのはなぜですか?サニタイザーの出力はここにありますが、信じてください、300 バイト未満です.GB のリークではありません.)
watchメモリ (仮想メモリ) の状態を見ていると、しばらくするとコマンドの出力が表示されます。
、、およびすべてVmPeakは、他のデーモンが実行されるたびに増加します (約 5 分ごとに 1 回)。VmSizeVmData
ただし、メモリ (malloc/free) は変更されていません。私は今ログに記録していますsbrk(0)(1201ProgramAlarm のコメントによるアイデア - 彼のコメントの最初の部分の私の解釈) とそのアドレスは同じままです:
博士号が示唆したように、私は/proc/<pid>/maps時間をかけて内容を調べました。ここでは、1 つまたは 2 つの増分があります。残念ながら、これらのバッファーを作成するものについては知らされていません。私が考えることができる唯一のものは私のスレッドです...(つまり、スタックとスレッドステータス用の小さなスペース)
ああ…うん!私の最近の変更は、切り離されたスレッドから参加することです...実際にはスレッドにまったく参加しません。今すぐ適切な結合でテストしてください...そして正しく動作します! じぶんの!悪いやつ!
c++ - Massif ビジュアライザーと ms_print のサイズの違い
valgrind メモリ使用ツール massif を使用しようとしています。しかし、valgrind --massif output .out の出力をプログラム ms_print および massiff ビジュアライザー アプリで視覚化しようとすると問題が発生します。
ms_print と Massiff ビジュアライザー アプリ ( http://milianw.de/tag/massif-visualizer ) には 2KiB の違いがあります。
不足しているものはありますか? 両方のスクリーンショットを追加しました。
ありがとう
c++ - Massif と time で最大 RSS を取得するためにメモリをプロファイリングする際の異なる結果
ちょっとしたコンテキスト:mmap読み取りと書き込み用にいくつかの任意の大きなファイルをマップするために使用する C++ アプリケーションを実装しようとしています。これは、数 MB から数 GB にスケーリングできます。このため、プログラムのパフォーマンスを確認するには、プログラムのメモリ使用量 (ピーク RSS、物理メモリの消費量を確認したい) をプロファイリングすることが重要です。
Valgrind の massif ツールをオプションpages-as-heap=yesとで使用しますmassif visualizer。これで RSS のピークが表示されると思います。mmap正確に1GBを予約してプログラムを実行します。Massif-visualizer は、予想どおり (1GB ピーク) を示しました(画像を参照)。
コマンドも使用\time -vしたところ、最大 RSS のサイズが非常に小さいことがわかりました (5000 キロバイト程度)。出力例を次に示します。
timeまた、メモリ スナップショットのデルタが十分でない場合に備えて、プログラムをより長く実行できるように変更しましたが、同じ結果が得られました。
メモリのピークが異なるのはなぜですか? 私がいくつかの投稿で読んだことから、人々はpages-as-heap=yesオプションを指定して Massif を期待すると、そのピークとなる最大 RSS が表示されます。\timeただし、はるかに小さいピークを示すコマンド出力には違いがあります。massif のスナップショットは仮想メモリに関するものだと思いますが、間違っていたら訂正してください。さらに、massif に詳しい方がどのように機能するか、また最大 RSS を取得する方法があれば教えていただければ幸いです。前もって感謝します!
編集:ここでの答えは、私の質問に部分的に答えているようです: mmap または malloc は RAM を割り当てますか?
私が理解している限り、ほとんどの OS システムでは、ファイルをメモリにマップすると、物理メモリ空間ではなく仮想空間を占有します。ただし、マップされたページは、ダーティになるとすぐに物理メモリ空間を占有し始めます。つまり、ページに何かが書き込まれます。
それで、私の最初の質問に戻りますが、これは、フラグ付きの valgrind massif が--pages-as-heap=yes仮想メモリ空間を追跡する一方\time -vで、ページが変更されていないという事実のために物理メモリをあまり表示しないことを意味しますか?


