自分のホームディレクトリとすべてのサブディレクトリを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？
私は2つの質問をしています：具体的で漸近的な複雑さのコスト（まだカーネルスタックのどの部分がデータ構造を持っているのか、そしてどのようにinotify実装に接続するのか調べていません）。
私の言葉は、コンピューティング、メモリ、その他のコストです。
私の考えでは、これは関数です（KiBで具体的な数字またはCPU負荷の見積もり（良いベンチマークがある可能性があります）、または漸近的に（たとえば「ioあたり」））。
- 監視するファイル/ディレクトリ
- ファイル/ディレクトリで実行される操作
- inotify はキューの長さを監視します。
しかし、私が何かを見逃しているのではないでしょうか？
まだスキーマを調査していないが監視されていないノード/ディレクトリ/ファイル/パスの操作に影響を与えるかどうか疑問に思います。
繰り返しますが、どのような違いがありますかfanotify？
ベストアンサー1
私はinotifywatchを使用せずにgidgetを使用しているので、私の答えはそのツールに限定されず、単にinotifyの有用な観察にすぎません。重く使用）。
各inotifyモニターは、32ビットアーキテクチャでは540バイトのカーネルメモリを使用し、64ビットアーキテクチャでは1080バイトを使用します。カーネルメモリは交換できません。だから確かにメモリコストが発生します。
しかし、私の経験上、速度を遅くすることは監視回数ではなく、カーネルが迅速にチェックします。実際の使用でシステムのパフォーマンスに影響を与える可能性が最も高いのは、inotifyイベントがトリガーされたときに実行することです。たとえば、ギガビットまたは10ギガビットリンクを介して回線速度で到着するHIPAA準拠の835ファイルが10〜4万個ある場合、各ファイルを処理するためのユーザープロセスを開始することは、Inotify Impact自体よりもシステムに負担がかかる与えます。
ただし、あなたの質問の1つ以上に答える場合はいいえ、監視設定は監視されていないファイルやフォルダに影響/費用を与えません。コアいつもモニター・セットがあるかどうかを確認するには、モニター・セットがない限り、モニターされる他のファイル・システム・オブジェクトの数に関係なく、同じ時間とリソースが必要です。しかし、もう一度お話ししますが、理由が何であれ、何度も何度もプロセスを作成すると、これは確かにシステム全体のパフォーマンスに影響を与えます。
また、使用しているツールがフォルダとサブフォルダを繰り返し監視できることにも言及しました。これはinotifyが実行するものではなく、ツールが実行するものです。指定したサブフォルダのフォルダを検索し、すべてのフォルダに監視を設定してから、新しい監視が作成されたときに別の監視を設定するようにトリガできます。したがって、inotifyシステムと間接的にのみ関連するいくつかのオーバーヘッドアクティビティを実行することになり、パフォーマンスへの影響は主にinotifyの動作ではなくツールの動作に起因します。ツールが粗雑でリソースが非効率的である場合、問題になる可能性があります。 （わかりませんが、inotifyツールは通常Cで書かれているので疑わしいです。）