問題タブ [google-perftools]

google-perftools パッケージに pprof ユーティリティがあります。https://github.com/gperftools/gperftools/tree/master/doc/pprof-test-big.gifや https://githubのように、google-perftools cpuprofiler と heapprofiler のプロファイル ファイルを美しい画像に変換するユーティリティです。.com/gperftools/gperftools/tree/master/doc/heap-example1.png

cpu プロファイルの pprof の入力ファイルの形式は、https ://github.com/gperftools/gperftools/tree/master/doc/cpuprofile-fileformat.html で説明されています。

ただし、heap profile入力ファイルの形式は svn に記述されていません。

「ヒープロファイリング」形式とは何ですか? また、コードからそのようなファイルを生成するにはどうすればよいですか? 私はすでに cpuprofiler 形式を生成できるので、2 つの形式の違いに興味がありました。

ご存知の方もいらっしゃるかもしれませんが、Googleがc ++コードを分析するためのツールの無料のすばらしいコレクションを提供しています： http ：//code.google.com/p/google-perftools/

問題は、64ビットで明らかにlibunwindの問題があり、作成者がそれを修正するために自分の側で何もできないことです（

しかし、私はすぐに修正されるとは思っていません。それは、libcの人々とlibunwindの人々がいくつかのロックの問題を解決することに依存しています。残念ながら、私たち自身ができることはあまりありません。

）、だから私は代替品を探しています。プロファイリングデータのクールなグラフィック表現を提供する同様のツールはありますか（例:)

）。

編集：問題を説明するREADMEから貼り付けます：

2）x86-64 64ビットシステムでは、tcmalloc自体は正常に機能しますが、cpu-profilerツールは信頼性がありません。機能する場合もありますが、セグメンテーション違反が発生する場合もあります。最初に問題を説明し、次にいくつかの回避策を説明します。

これは、CPUPROFILE環境変数を設定して手動でオンにする必要があるgoogle-perftools機能であるcpu-profilerにのみ影響することに注意してください。CPUプロファイリングをオンにしない場合、perftoolsが原因でクラッシュが発生することはありません。

厄介な詳細：根本的な問題は、libcの組み込み関数であるbacktrace（）関数にあります。通常の場合、バックトレースはかなり簡単ですが、信号フレーム全体をバックトレースする必要がある場合に問題が発生する可能性があります。残念ながら、cpu-profilerはプロファイリングイベントを登録するために信号を使用するため、プロファイラーが実行するすべてのバックトレースは信号フレームを通過します。

私たちの経験では、問題が発生するのは、pthread_mutex_lockの途中で信号が発生したときだけです。pthread_mutex_lockは、特にプログラムの起動時や新しいスレッドの作成時に、システムライブラリからかなり呼び出されます。

解決策：dwarfデバッグ形式では、「cfiアノテーション」がサポートされているため、信号フレームを簡単に認識できます。Fedoraやgentoo2007.0などの一部のOSディストリビューションでは、すでにcfiアノテーションがlibcに追加されています。libunwindの将来のバージョンでは、これらのアノテーションを認識する必要があります。これらのシステムはクラッシュを認識しないはずです。

回避策：cpu-profilerの実行中にクラッシュの問題が発生した場合は、CPUPROFILEを設定するのではなく、コードにProfilerStart（）/ ProfilerStop（）を挿入することを検討してください。これにより、コードベースのそれらのセクションのみがプロファイルされます。多くのテストは行っていませんが、理論的には、信号の生成をコードベースのごく一部に制限することで、クラッシュの可能性を減らすことができます。理想的には、新しいスレッドを生成するコードの周りでProfilerStart（）/ ProfilerStop（）を使用しないか、そうでなければpthread_mutex_lockの呼び出しを引き起こす可能性があります。

---2011年5月17日

google-perftoolsC++ で記述され、g++4.5.2 でコンパイルされたプログラムのプロファイリングに使用しています。CPU 時間の 56% を占めpprofていることがわかります。getaliasbyname_r()いったい何をするのgetaliasbyname_r()？なぜそんなにCPU時間がかかるのですか？この問題を軽減する方法はありますか? ありがとう。コンパイル フラグは次のとおり-O3 -DNDEBUG -Wall -Wno-deprecated -Wno-sign-compareです。システム：ubuntu 11.04。

質問を明確にしておらず申し訳ありません。コードで getaliasbyname_r() を直接使用しませんでした。プロファイリング ツール「pprof」によって生成されたコール グラフでは、ツリー「start--> _libc_start_main-->main-->...」が約 44% の cputime をカウントしていることがわかります。この大きなツリーの他に、コール グラフには別の ioslated 単一ノード ツリー --- getaliasbyname_r があります。グラフに示されているように、それは呼び出されず、他の関数からも呼び出されませんでした。この関数をグーグルで検索したところ、http://linux.die.net/man/3/getaliasbyname_rにたどり着きました。しかし、それはあまり役に立ちませんでした。getaliasbyname_r() がどのように呼び出されたのか、なぜそんなに多くの cputime がかかったのか、まだわかりません。この質問は今意味がありますか？

エイドリアンへの返信: 返信ありがとうございます。合計実行時間は約 28 秒でした。プロファイラーは 100/秒のレートでサンプリングします。合計で約 2800 のサンプルがありました。約 1500 が getaliasbyname_r() で落ち、私が書いた関数を思いつきました (約 450 のサンプルをキャッチしました)。

Debian スクイーズ オペレーティング システム (64 ビット) を使用しています。google-perftools で python を使いたいです。それを実行するために、オプション「-lctmalloc」を使用して自分でpython 2.72をコンパイルしました。しかし、私はほとんどエラーが発生しません。

1. 64ビットを使用しているときにgoogle-perftoolがこのパッケージを要求するため、libuwindをインストールしました
2. 必要なすべてのパッケージをインストールしました：

手順:

そして、それは私が得たものです:

CFLAGS='-ltcmalloc' なしでまったく同じことを行うと、このエラーが本当にわかりません。コンパイルできます。ご協力ありがとうございました。

テストスイートを高速化するために、プロファイルを作成し、次の結果を取得しました

この回答からKernel#require がアプリケーションのリソースを大量に消費するのはなぜですか? これは予想どおりのようですが、ここの膨大な数に本当に驚いています。これは本当ですか？私たちはそれについて何もできませんか？

通常実行するテスト スイートのプロファイルをbundle exec rspec spec/作成し、GIF 画像を生成する必要があります。

バンドラーで正しく動作するようにperftools.rbを実行するコマンドは何ですか?

sudo gem install perftools.rb -p http://10.10.10.10:3128 ...

/usr/local/lib/ruby/1.9.1/net/http.rb:762:in "initialize": 接続が拒否されました - connect(2) (Errno::ECONNREFUSED)

...

http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p0.tar.gzをリクエスト中

メッセージ全文:

ソースからのコンパイルには ruby​​ ソースが必要なようで、ruby サイトから直接ダウンロードしようとします。http プロキシ経由で perftools.rb をインストールするにはどうすればよいですか?

C++ プログラムでデフォルトのメモリ アロケーションとして google-perftools の tcmalloc_minimal を使用しています。次の情報が出力されます。

そして、プログラムは実行を続けます。それは問題ですか？

MacOSX でいくつかの C++ プログラムをプロファイリングしようとしています。そこで私は をビルドgoogle-perftoolsし、プログラムを書き、MacPorts g++ 4.7 を使用してコンパイルし、-gコンパイラ フラグを付けて にリンクしましたlibprofiler。それから私は走った：

次に、pprof を実行して出力を生成しました。

perftools がアドレスを関数名に変換していないようです。

ここで何が欠けているか知っている人はいますか？プロファイラーが正しい結果を生成できるようにするにはどうすればよいですか?

編集: 詳細: pprof や google-perftools の問題ではなく、gcc や macosx などの問題です。Instrument.app も行番号の代わりにアドレスを表示するためです。私は Mac OS X でデバッグ シンボルがどのように機能するかについてよく知らないので、gcc や Mac OS X のバグではなく、ここで何かが欠けていると考えたいと思います。 Mac OS X 用。

Google CPU パフォーマンス ツールを使用してプログラムのプロファイルを作成しようとしていますが、.prof ファイルを分析しようとすると、次のようなエラーが発生します。

最初は、あまりにも多くの呼び出しをプロファイリングしようとしていると思ったので、プログラムの実行時間を短縮しました (タイムステップベースなので、実行を短くするのは簡単です) が、それでも同じエラーが発生しました。これを回避するための助けをいただければ幸いです。