ホームディレクトリとすべてのサブディレクトリを 60 秒間再帰的に監視するには:
$ inotifywatch -v -r -t 60 /path
エラーが発生する可能性がありますがFailed to watch /path; upper limit on inotify watches reached!、制限を例えば 128k に上げることで修正できます。# echo $[ 128*1024 ] | tee /proc/sys/fs/inotify/max_user_watches
そこで私は疑問に思いました。
n 個の時計を所有すると、具体的にはどのようなコストがinotifyかかりますか?
私は、具体的な複雑さと漸近的な複雑さの両方のコストについて質問します (カーネル スタックのどの部分のどのデータ構造が、inotify の実装としてどのようにフックされるかについてはまだ詳しく調べていません)。
つまり、計算コスト、メモリコスト、その他のコストです。
これらは、次のような関数 (KiB 単位の具体的な数値、CPU 負荷の推定値 (優れたベンチマークがあるかもしれません)、または漸近的なもの (例: 「各 io 」) ) であると想像します。
- 監視対象のファイル/ディレクトリ
- 実行されたファイル/ディレクトリの操作
- inotify 監視キューの長さ
でも、何か見逃したのかな？
まだアーキテクチャを詳しく調べていませんが、監視されていない inode/ディレクトリ/ファイル/パスに対する操作に影響するかどうか疑問に思います。
同様に、 の場合はどう違うのでしょうかfanotify?
答え1
私はinotifywatchではなくgidgetを使っているので、私の回答はそのツールに特有のものではなく、inotify（私が重く使用）。
各 inotify ウォッチは、32 ビット アーキテクチャでは 540 バイトのカーネル メモリを使用し、64 ビット アーキテクチャでは 1080 バイトを使用します。カーネル メモリはスワップできません。したがって、メモリ コストは確かに発生します。
しかし、私の経験では、監視の数が速度を低下させるわけではありません。カーネルが監視を素早くチェックします。実際の使用でシステム パフォーマンスに影響を与えるのは、inotify イベントがトリガーされたときに何を行っているかです。たとえば、1 万から 4 万の HIPAA 準拠の 835 ファイルがギガビットまたは 10 ギガのリンクを介してワイヤ スピードで到着する場合、各ファイルを処理するために起動されるユーザー プロセスは、inotify 自体よりもはるかに大きな負荷をシステムに与えることになります。
ただし、質問の少なくとも1つに答えると、いいえ、監視を設定しても監視されていないファイルやフォルダには影響やコストは発生しません。カーネルいつも監視が設定されているかどうかをチェックします。監視が設定されていない限り、他のファイルシステム オブジェクトがいくつ監視されているかに関係なく、チェックにかかる時間とリソースは同じです。ただし、(何らかの理由で) 膨大な数のプロセスを継続的に生成している場合は、システム全体のパフォーマンスに確実に影響します。
また、使用しているツールはフォルダーとサブフォルダーを再帰的に監視できるとおっしゃっていました。これは inotify が行うことではなく、ツールが行っていることです。おそらく、サブフォルダーの対象フォルダーをスキャンし、それらすべてに監視を設定し、新しいサブフォルダーが作成されたときにトリガーして別の監視を設定します。したがって、inotify システムに間接的にしか関連しないオーバーヘッド アクティビティが発生しており、パフォーマンスへの影響は主にツールの動作によるものであり、inotify の動作によるものではありません。ツールがずさんでリソース効率が悪い場合 (inotify ツールは通常 C で記述されているため、わかりませんが、疑わしいです)、これが問題になる可能性があります。