Para observar mi directorio de inicio y todos los subdirectorios de forma recursiva durante 60 segundos:
$ inotifywatch -v -r -t 60 /path
Es posible que obtenga Failed to watch /path; upper limit on inotify watches reached!un error, que puede solucionar aumentando el límite, por ejemplo, a 128k:# echo $[ 128*1024 ] | tee /proc/sys/fs/inotify/max_user_watches
Esto me hizo preguntarme:
¿Qué costes exactos supone tener n inotifyrelojes?
Pregunto en ambos: costos de complejidades concretas y asintóticas (aún no investigué, qué estructuras de datos en qué partes de la pila del kernel y cómo se conectan como implementación de inotify).
Quiero decir: costos computacionales, de memoria y otros.
Me imagino que serán funciones (que dan números concretos en KiB, o estimaciones de la carga de la CPU (tal vez haya algunos buenos puntos de referencia), o incluso asintóticas (por ejemplo, "cada io)) de:
- archivos/directorios observados
- operaciones en archivos/directorios realizados
- longitudes de las colas de relojes inotify
¿Pero tal vez me he perdido algo?
Todavía no profundicé en la arquitectura, pero me pregunto si afecta las operaciones en inodos/directorios/archivos/rutas no supervisados.
De manera similar, ¿en qué se diferencia fanotify?
Respuesta1
No uso inotifywatch, uso gidget, por lo que mi respuesta no es específica de esa herramienta, es solo una observación que espero sea útil sobre inotify (quefuertementeusar).
Cada reloj inotify utiliza 540 bytes de memoria del kernel en arquitecturas de 32 bits y 1080 bytes en arquitecturas de 64 bits. La memoria del kernel no es intercambiable. Así que ciertamente hay un costo de memoria.
Pero en mi experiencia no es el número de relojes lo que ralentiza las cosas: el núcleo los comprueba rápidamente. Lo que tiende a afectar el rendimiento del sistema, en el uso real, es lo que esté haciendo cuando se activan los eventos de notificación. Si tiene (por ejemplo) de diez a cuarenta mil archivos 835 compatibles con HIPAA que llegan a velocidad de cable a través de un enlace de gigabit o diez gigas, los procesos de usuario que se activan para tratar con cada uno de ellos golpearán al sistema mucho más fuerte que el propio sistema de notificación.
Sin embargo, para responder al menos a una de sus preguntas: No, configurar la vigilancia no tendrá ningún efecto ni costo para los archivos o carpetas no vigilados. el núcleosiemprecomprueba si hay un conjunto de vigilancia, y la comprobación tomará la misma cantidad de tiempo y recursos siempre que no haya uno, sin importar cuántos otros objetos del sistema de archivos se estén vigilando. Pero nuevamente, si constantemente genera una gran cantidad de procesos (por cualquier motivo), eso definitivamente tendrá un impacto en el rendimiento total del sistema.
Además, mencionaste que la herramienta que estás utilizando puede observar carpetas y subcarpetas de forma recursiva. Eso no es algo que haga inotify, es algo que está haciendo su herramienta. Probablemente esté escaneando la carpeta a la que ha seleccionado subcarpetas, configurando vigilancias en todas ellas y luego activando cada vez que se crea una nueva para configurar otra vigilancia. Entonces, hay alguna actividad general que está solo indirectamente relacionada con el sistema inotify, y el impacto que tiene en el rendimiento se debe principalmente al comportamiento de la herramienta, no al comportamiento de inotify. Si la herramienta es descuidada y ineficiente en cuanto a recursos (no lo sé, pero lo dudo, ya que las herramientas de inotify generalmente están escritas en C), esto podría ser un problema.