12

ロギングはアプリケーションのパフォーマンスを低下させますか? また、表示タグのログをログ ファイルに出力するように制限する方法は?

例えば。私のログファイルには以下のログがあります

[2012-06-20 15:52:06,290] org.displaytag.tags.TableTag isFirstIteration 684 - [data] first iteration=true (row number=1)
[2012-06-20 15:52:06,290] org.displaytag.tags.TableTag isFirstIteration 684 - [data] first iteration=true (row number=1)
[2012-06-20 15:52:06,290] org.displaytag.tags.TableTag isFirstIteration 684 - [data] first iteration=true (row number=1)
[2012-06-20 15:52:06,290] org.displaytag.tags.TableTag isFirstIteration 684 - [data] first iteration=true (row number=1)

上記がログファイルにあるのはなぜですか？

log.properties ファイル

# Log4j configuration file.
 log4j.rootCategory=DEBUG, A1
 # Available levels are DEBUG, INFO, WARN, ERROR, FATAL

 #
 # A1 is a ConsoleAppender 
 #

log4j.appender.A1 = org.apache.log4j.RollingFileAppender
log4j.appender.A1.File = C:/LogInfo/logfile.log
log4j.appender.A1.MaxFileSize = 100MB
log4j.appender.A1.MaxBackupIndex=50
log4j.appender.A1.layout = org.apache.log4j.PatternLayout
log4j.appender.A1.append = true
log4j.appender.A1.layout.ConversionPattern = [%d] %C %M %L - %m%n
log4j.appender.A1.Threshold = DEBUG

ログファイルに出力されるこの種のログを停止する方法 (org.displaytag.tags.TableTag)

4

6 に答える 6

11

ロギングはアプリケーションのパフォーマンスを低下させますか?

はい。それがどれだけのことをするかは、多くの要因に依存します。下記参照。

また、表示タグのログをログ ファイルに出力するように制限する方法は?

ロギング プロパティの ConversionPattern を変更する

上記がログファイルにあるのはなぜですか？

なぜなら：

  1. debug(String)コードのどこかで、そのメッセージを使用して Logger メソッド (おそらく ) が呼び出されており、
  2. ログのプロパティは、アペンダーのログのしきい値を DEBUG に設定します。

パフォーマンスを向上させるには:

  1. ConversionPattern をより安価な日付/時刻形式を使用するように変更し、(さらに重要なことに) 'C'、'F'、'L'、および 'M' は特にコストがかかるため避けてください。
  2. ログのしきい値を INFO または WARNING または ERROR に変更して、ログの量を減らします。
  3. デバッグ ログが有効になっていることを確認Logger.debug(...)するステートメント内に呼び出しを配置し​​ます。ifこれにより、ログ メッセージが不要な場合にログ メッセージを組み立てるコストが節約されます。log4j では、ログを記録する前に isDebugEnabled をチェックするとパフォーマンスが向上しますか?を参照してください。.
  4. log4j バージョン 2 (log4j2) では、フォーマットとパラメーターを取るロギング メソッドにオーバーロードがあります。これらは、無効化されたレベルでログを記録するときのオーバーヘッドを削減します。
  5. logback と log4j 2.0 も見てください。

また、 log4j のドキュメントLoggerで説明されているように、レベルでログを調整することもできます。実際、このドキュメントには、あなたが尋ねたほとんどの質問への回答があり、ログのパフォーマンスとログの構成のトピックについて多くの詳細が記載されています。

于 2012-06-20T10:55:39.713 に答える
3

簡単な答え: はい、一部の CPU サイクルやその他のリソース (メモリなど) を使用するため、アプリケーションのパフォーマンスが低下します。

この質問も参照してください：log4jのパフォーマンス

于 2012-06-20T10:50:30.770 に答える
1

ロギングは、CPU 時間の 30% 以上になる場合があります。ジッターに関しては、GC遅延と同じくらい（そしてより頻繁に）大きくなります。

オーバーヘッドを削減する簡単な方法は、パターンを使用して各メッセージのログをオフにすることです。あなたの場合、これは %C %M と %L です。この情報を取得するには、(スタック全体の) スタック トレースを取得する必要があるためです。

于 2012-06-20T10:55:11.850 に答える
0

はい、彼らがやります。そのため、エラーまたは絶対にログに記録する必要があるものだけをログに記録する必要があります。また、デバッグ チャネルでのデバッグに役立つ情報をログに記録できるため、本番環境のパフォーマンスに影響を与えることはありません。

于 2012-06-20T10:50:29.810 に答える
0

このように迷惑ログを制限できます。不要なデバッグ ログが来てログ ファイルがいっぱいにならないように、ルート ロガーを INFO として設定します。

log4j.rootCategory=INFO, A1

特定のクラスまたはパッケージに DEBUG ログを発行させたい場合は、次のように実行できます。

log4j.logger.org.hibernate.event.def.DefaultLoadEventListener=DEBUG,A1

上記は、ログ ファイル内のクラス DefaultLoadEventListener からの DEBUG レベルのログを、他の INFO レベルのログと共に出力します。

于 2012-06-20T10:56:09.820 に答える
0

どうですか？

log4j.category.org.displaytag.tags.TableTag=ERROR, A1
于 2012-06-20T10:59:11.727 に答える