私はperf
linux-2.6.36-gentoo-r4を使用しています。 0に設定する/proc/sys/kernel/perf_event_paranoid
と問題は発生しません。
プロファイリング中の長期実行アプリケーションが不特定の理由でクラッシュすることが多かったため(動作が停止した理由に関する情報が見つかりませんでした)、システム全体のプロファイリングにパフォーマンスイベントを使用するようになりました。
関連アプリケーションはMPI(Message Passing Interface)を使用して通信し、並列数値計算を実行します。アプリケーションを実行する前に(を使用してmpirun
)、次の場所でシステム全体のプロファイルデータのロギングを開始しました。一つ実行中のノード数:
$ perf record -o perf.all.cycles,graph.data -g -e cycles -a &
アプリケーションがクラッシュしたことがわかったら、ジョブをperf
終了しました。
それは去った
$ du -sh perf.all.cycles,graph.data
14G perf.all.cycles,graph.data
14GBデータ。残念ながら、移行はサポートperf report
されていません-a
。
ツールを使用してperf
システム全体の分析データを分析する方法?
2011.08.12に追加
単に実行すると、perf report
有用な出力は生成されません。
$ perf report -i perf.all.cycles,graph.data
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
14GBプロファイルデータのフル出力です...
ベストアンサー1
MPI を使用して計算を分散する場合、MPI 認識ツールを使用すると、よりスマートな結果が得られます。分散アプリケーションでは、あるMPIプロセスが別のプロセスからの入力を待っている間にアイドル状態の負荷不均衡の問題が発生する可能性があります。このMPIプロセスを正確に分析した場合、パフォーマンス分析は完全に間違っています。
したがって、最初のステップは通常、プログラムの通信とロードバランシングパターンを理解し、必要なワークロード(レベル0のCPU集約型)を提供するサンプル入力を識別することです。例えば、 ミップ通信パターン、各MPI呼び出しに費やされた時間などの非常に完全なレポートを生成するMPI分析ツール。
その後、選択した 1 つ以上の MPI レベルでコード分析ツールを実行できます。とにかく、単一のMPIレベルでそれを使用するのは良い考えではありませんperf
。その測定にはMPIライブラリコードのパフォーマンスも含まれます。これはおそらく望むものではないかもしれません。