performance - 多くのスタックトレースをログに記録するのはどれほど悪いことですか？

Question

ログファイルに多くのスタックトレースがあるのはそれほど悪くありませんか？

つまり、何かがうまくいかないかどうかを確認できます。それがどこから来ているかを確認できます。

しかし、パフォーマンスはどうですか？このようなロギング形式のアプリケーションにとって、どれほどひどいことになるでしょうか。

一般的なロガーでスタックトレースがある場合とない場合のログをシステムで切り替えるにはどうすればよいですか？ログレベル経由？

Answer 1

通常、ログ ファイルにスタック トレースを記録することをお勧めします。問題のコードを見つけやすくなります。

スタックトレース生成のパフォーマンスのみに関心がある場合は、Java で例外をスローするのにかかる時間についての記事を書きました。ほとんどの時間はスタック トレースの生成に費やされていました: Java での例外のスローは非常に遅い

Answer 2

壁時計の時間割り込みでトリガーされるスタック トレースについて話していると思いますか? これらは、パフォーマンスの問題を特定するのに役立ちます。(関数/メソッド名だけでなく、呼び出しが行われる行番号情報が含まれていると、はるかに価値があります。)

ただし、それらは調べることができて初めて価値があり、何百万も調べることはできないため、高頻度に近いものを取得しても意味がありません。修正する価値があるほど大きなパフォーマンス上の問題のほとんどは、20 個以下のスタック サンプルで見つけることができます。多くの人がその数に驚くと思いますが、これが計算です。

原則として、統計サマライザーがあれば、Zoomプロファイラーと同様に、より多くのデータを使用できますが、実際には手動で行う方が適切です。なぜなら、脳は無駄な処理をどの統計よりもよく認識できるからです。