私はinotifyを介してファイルイベントを監視し、ファイルがアクセスされたときにさまざまなタイプのイベントをトリガーするデーモンに取り組んでいます。カーネルは監視されているすべてのファイルの完全パス名を格納しているため、監視は少し高価であると私は読んだ。
時計の数は多すぎますか?
編集:ほとんどの場合、気になるのは..パフォーマンスが著しく低下したことはありますか?はい、私は再帰的に監視する必要があります(ただし、最小限のブートストラップシステム)。
私の知る限り、カーネルはパス名を保存していませんが、iノードを保存しています。それにもかかわらず、32ビットシステムではWatchごとに540バイトあります。 64ビットでは倍になります。
100万の時計を持っているLsyncd(多分それをチェックしたいですか?)の人から知っています。ギガバイトのメモリを消費するだけです。
/proc/sys/fs/inotify/max_user_instances
(inotifyの「オブジェクト」の最大数)と/proc/sys/fs/inotify/max_user_watches
(監視するファイルの最大数)を読み取ることでシステムの制限を見つけることができるため、これらの数を超えると多すぎます;-)監視の最大数は通常数万以上です-私のシステムでは262143-これはおそらく、ファイルシステムのすべてのファイルを監視しようとしない限り、必要以上の数ですが、実行してはなりません。それ。必要以上にinotifyウォッチを使用しないようにし、パフォーマンスの大幅な低下に気付かない限り、心配しないでください。
私の情報:
[foo@caffeine ~]# cat /var/log/lsyncd.status | grep Inotify
Inotify watching 293208 directories
[foo@caffeine ~]# cat /proc/sys/fs/inotify/max_user_watches
1048576
lsyncdは約130Mのメモリを使用します。
Lsyncdを使用して、いくつかのディレクトリをディザスタリカバリサーバーと同期させます。
メインサーバーでのパフォーマンスヒット/ペナルティはありません。
おそらく1,000兆兆の兆兆は多すぎるでしょう。 Kernel Korner-Intro to inotify は「数千の時計」について言及しているため、少なくともその数は問題になりません。
それはあなたが持っているラムの量に依存します
524288は監視できるファイルの最大数ですが、特にメモリに制約のある環境にいる場合は、その数を減らすことをお勧めします。各ファイルウォッチは540バイト(32ビット)または〜1kB(64ビット)を消費するため、すべての524288ウォッチが消費され、上限が約256MB(32ビット)または512MB(64ビット)になると想定します。 。