Um mein Home-Verzeichnis und alle Unterverzeichnisse 60 Sekunden lang rekursiv zu überwachen:
$ inotifywatch -v -r -t 60 /path
Möglicherweise tritt Failed to watch /path; upper limit on inotify watches reached!ein Fehler auf, den Sie beheben können, indem Sie das Limit erhöhen, z. B. auf 128 K:# echo $[ 128*1024 ] | tee /proc/sys/fs/inotify/max_user_watches
Das hat mich zum Nachdenken gebracht:
Welche genauen Kosten inotifyentstehen durch den Besitz von n Uhren?
Ich frage sowohl nach den Kosten konkreter als auch asyphotischer Komplexität (ich habe noch nicht herausgefunden, welche Datenstrukturen an welchen Teilen des Kernel-Stacks und wie bei der Implementierung von inotify eingebunden werden).
Ich meine: Rechen-, Speicher- und sonstige Kosten.
Ich stelle mir vor, dass es sich dabei um Funktionen handelt (die konkrete Zahlen in KiB oder Schätzungen der CPU-Auslastung liefern (vielleicht gibt es einige gute Benchmarks) oder sogar asymptotische Funktionen (z. B. „each io“)) von:
- Überwachte Dateien/Verzeichnisse
- Durchgeführte Operationen an Dateien/Verzeichnissen
- Längen der Inotify-Watch-Warteschlangen
aber vielleicht habe ich etwas übersehen?
Ich habe mich noch nicht mit der Architektur befasst, frage mich aber, ob sie Vorgänge auf nicht überwachten Inodes/Verzeichnissen/Dateien/Pfaden beeinflusst?
Und worin liegt der Unterschied bei fanotify?
Antwort1
Ich verwende nicht inotifywatch, sondern gidget, daher ist meine Antwort nicht spezifisch auf dieses Tool, sondern nur eine hoffentlich nützliche Beobachtung zu inotify (was ichschwerverwenden).
Jede Inotify-Überwachung verwendet 540 Byte Kernelspeicher auf 32-Bit-Architekturen und 1080 Byte auf 64-Bit-Architekturen. Der Kernelspeicher ist nicht austauschbar. Es gibt also sicherlich Speicherkosten.
Aber meiner Erfahrung nach ist es nicht die Anzahl der Überwachungen, die die Dinge verlangsamt - der Kernel prüft sie schnell. Was sich im realen Einsatz tendenziell auf die Systemleistung auswirkt, ist das, was Sie tun, wenn die Inotify-Ereignisse ausgelöst werden. Wenn Sie beispielsweise zehn- bis vierzigtausend HIPAA-kompatible 835-Dateien haben, die mit Leitungsgeschwindigkeit über eine Gigabit- oder Zehn-Gigabit-Verbindung ankommen, werden die Benutzerprozesse, die gestartet werden, um jede einzelne Datei zu verarbeiten, das System weitaus stärker belasten als Inotify selbst.
Um jedoch zumindest eine Ihrer Fragen zu beantworten: Nein, das Setzen von Überwachungen hat keine Auswirkungen/Kosten für nicht überwachte Dateien oder Ordner. Der Kernelstetsprüft, ob eine Überwachung eingestellt ist, und die Prüfung wird genauso viel Zeit und Ressourcen in Anspruch nehmen, solange keine Überwachung eingestellt ist, unabhängig davon, wie viele andere Dateisystemobjekte überwacht werden. Aber noch einmal: Wenn Sie ständig eine große Anzahl von Prozessen generieren (aus welchem Grund auch immer), wird sich das definitiv auf die Gesamtleistung des Systems auswirken.
Sie haben auch erwähnt, dass das von Ihnen verwendete Tool Ordner und Unterordner rekursiv überwachen kann. Das ist nicht etwas, was inotify macht, sondern etwas, was Ihr Tool macht. Es durchsucht wahrscheinlich den von Ihnen ausgewählten Ordner nach Unterordnern, richtet für alle eine Überwachung ein und löst dann jedes Mal, wenn ein neuer Ordner erstellt wird, eine weitere Überwachung aus. Sie haben also einige Overhead-Aktivitäten, die nur indirekt mit dem inotify-System zusammenhängen, und die Auswirkungen auf die Leistung werden hauptsächlich auf das Verhalten des Tools und nicht auf das Verhalten von inotify zurückzuführen sein. Wenn das Tool schlampig und ressourcenineffizient ist (ich weiß es nicht, aber ich bezweifle es irgendwie, da inotify-Tools normalerweise in C geschrieben sind), könnte dies ein Problem sein.