私は常にnohupシステムを起動するために使用します。しかし、出力がnohup大きすぎてこれを/dev/null。/dev/null
または、コードレベルまでドリルダウンしてこれらのログメッセージをすべて削除する必要がありますか？ （しかし必要かもしれません）。
唯一の関心事はI/O利用率とファイルサイズです。
答え1
記録されたデータは/dev/nullどこにも行きません。ファイルを書かないので、ファイルサイズには影響しません。
プログラムが書き込むと、/dev/nullシステムコールが発生します。ただし、システムコールはどこにもデータを書き込むことなくほぼすぐに返されます。したがって、アプリケーションの観点からはI / Oがありますが、ハードウェアの観点ではそうではありません。
手紙を書くのにかかる費用が大きすぎるかどうかは、あなた以外は誰も知りません/dev/null。悩んだらベンチマークしてみてください。
答え2
ちょっとそんな感じです。XYの問題。実際にする必要があるのは、構成ファイルまたはますます多くのコマンドラインを介してロギングレベルを制御する機能を追加することです-v。-vvv多くのコマンドラインツールと同様に。
nohupその後、追加/削除トグルを使用してサーバーを呼び出し、-vv..必要に応じて追加できます。
また、実際のロギングツールの使い方を見てください。log4j、log4perl、log4X ここで、Xはあなたの言語です。その後、log4X .conf ファイルでロギングレベルを制御し、ログの回転などのエントリを指定することもできます。
明らかにロギングはそのままリダイレクトできますが、/dev/null開発者はこれらの他のオプションも考慮する必要があります。
答え3
/dev/null への書き込みにはコストがゼロではありませんが、システムのパフォーマンスに影響を与える場合、ソフトウェアの作成者は何か大きな誤りをしました。 sys_write() 呼び出しは高度に最適化されています。転送されたデータ書き込みは、空のドライバに到達するまでさまざまなライブラリとカーネルシステムを通過します。この方法は非常に効率的です。
はい、プログラムには出力を無効にするフラグが必要ですが、そうでない場合は/dev/nullに書き込むとパフォーマンスの問題が発生した場合は奇妙なシステムがあります。
「急性の最適化はすべての悪の源である」を覚えなさい。この問題を解決するためにコードを編集することは、これが実際に最大のパフォーマンスボトルネックであることを示すベンチマークを最初に書くことができない場合は時間の無駄です。
歴史的記録：
Linuxの元のバージョンは/dev/nullが非常に遅かった。最後にデータを捨てるために多くの処理を行います。 Linuxの/ dev / nullがFreeBSDやSolaris（当時の人気のあるUnixファミリーシステム）よりはるかに遅いことを示す恥ずかしいベンチマーク（申し訳ありませんが、リンクが見つかりません！）があります。次のバージョンのLinuxでは、/dev/nullが高速になります。同様に、LinuxのループバックNICは、パケットを完全に処理し、CRCエラー（間違えない）を確認し、他の不要な作業を実行したため、非常に遅かったです。恥ずかしいほど悪いベンチマークが公開され、問題が迅速に修正されました。