3
現在、大規模なErlangアプリケーションでパフォーマンスの問題を調査中です。アプリケーションのCPU負荷が予想より大きくなっています。システムのどの部分が負荷の原因であるかを最初に把握するには、this answerに記載されているように、コールスタックサンプリングを実行したいと思います。Erlangのコールスタックサンプリング
これを行うには、erlang:process_info(Pid, backtrace)を繰り返し呼び出し、その出力から関数をグリッピングするよりも良い方法はありますか？
システムが大きすぎてfprofを使用できません。また、etopは私に正しい方向を指摘していないことに注意してください。 fprofをシステムの一部だけに使用することは、パフォーマンス問題の一般的な場所を特定する必要があるため、今は不可能です。
私はアーランを知らないが、私はその技術を知っている。デバッガの下でプログラムを実行し、手動で一時停止して、呼び出しスタックを調べることはできますか？パフォーマンスの問題の一般的な場所を最初に見つけることは心配しません。時間のほうが時間がかかるとそれが表示される確率であり、それが小さければチャンスはあなたが疑わないものです大きな割合を占めています。 –
@MikeDunlavey提案のおかげで（私はちょうどErlangのプロセスを中断して再開する方法を学んだので）。 Erlangは一時停止プロセスを許可していますが、コールスタックのサンプリングを単純化する方法はまだありません。 'erlang：process_info（Pid、backtrace）'では、実行時にスタックトレースを取得することができ、自分自身でプロセスを中断する必要はありません。しかし、私はその出力を解析して残されています。 – evnu
サンプリングをコードに入れることは重要ではありません。それは、プログラムの観点からは予測不可能な時に起こらなければならない。もう一つのポイントは、（広範な仮定に反して）たくさんのサンプルを必要としないということです。修正する価値があることを知るためには、問題を2回確認するだけでよく、そのために必要なサンプルの平均数は2/size_of_problemです。したがって、問題の発生時間が30％の場合、2回見てみるのに必要な平均サンプル数は2/0.30 = 6.67サンプルです。 –