0

ロガーのデバッグ出力の間に例外が発生したのはなぜですか?

  DEBUG: asdjoasjd
  DEBUG: asdjoasjd 
  DEBUG: asdjoasjd
  **RuntimeError: something**
  DEBUG: continued debug message
  DEBUG: continued debug message
  DEBUG: continued debug message

このデバッグ メッセージは例外の前に作成されましたか?

$stdout.sync = true助けられませんでした。

私はlog4rを使用しています

4

1 に答える 1

1

IO#syncドキュメントから:

同期モードが true の場合、すべての出力はすぐに基盤となるオペレーティング システムにフラッシュされ、内部でバッファリングされません。

これは、Ruby がデータを内部的にバッファリングしないことを意味します。残念ながら、これは OS のバッファリングについて何も意味するものではなく、OS もデータをバッファリングする可能性があります。

また、Log4r はIO#flushを使用してデータをフラッシュすることに注意してください。これにより、データが基盤となる OS にフラッシュされることが保証されますが、それ以上のことはありません。

ios 内のバッファリングされたデータを基礎となるオペレーティング システムにフラッシュします (これは Ruby の内部バッファリングのみであることに注意してください。OS もデータをバッファリングする場合があります)。

必要なのは、バッファリングされたすべてのデータを即座に書き込む (フラッシュする) IO#fsyncです。

ios にバッファリングされたすべてのデータをすぐにディスクに書き込みます。fsync は IO#sync= の使用とは異なることに注意してください。後者は、データが Ruby のバッファーからフラッシュされることを保証しますが、基盤となるオペレーティング システムが実際にデータをディスクに書き込むことを保証しません。

Log4r::StdoutOutputterをサブクラス化し、独自の#write実装を提供できます。

例：

module Log4r
  class SyncedStdoutOutputter < StdoutOutputter
    def write(data)
      super(data)
      @out.fsync
    rescue NotImplementedError
      # fsync not supported by this OS
    end
  end
end

特に本番システムでは、パフォーマンス上の理由から、バッファリングは適切であり、強く推奨されます。そうしないと、ディスクに不要な負担をかけるなど、不要なリソースを消費するリスクがあります。

Log4r個人的には、時代遅れで少し非アクティブだと思います。私は、ネイティブLoggerまたは少なくともActiveSupport::Logger（基本的にフォーマッターを提供する）のいずれかに固執しようとします。loggingなどのより最新の代替手段を見てください。ほとんどのロガーは交換可能です。

于 2015-09-08T23:09:09.187 に答える