I am working on a daemon that monitors file events via inotify to trigger various types of events when files are accessed. I have read that watches are a little expensive, because the Kernel is storing the full path name of every file being watched.
How many watches would be too many?
Edit: Mostly, I’m wondering .. have you ever seen a noticeable performance hit, if so, at how many watches did it happen? Yes, I have to monitor / recursively (however its a minimal bootstrapped system).
AFAIK the kernel isn’t storing the pathname, but the inode. Nevertheless, there are 540 bytes per Watch on a 32bit system. Double as much on 64bit.
I know from Lsyncd (maybe you want to check that out?) people who have a million watches. It just eats a Gigabyte of memory.
You can find the system limits by reading
/proc/sys/fs/inotify/max_user_instances (maximum number of inotify “objects”) and
/proc/sys/fs/inotify/max_user_watches (maximum number of files watched), so if you exceed those numbers, it’s too many 😉 The maximum number of watches is usually several tens of thousands or higher – on my system, 262143 – which is probably more than you’d ever need unless you’re trying to watch every file in a file system, but you shouldn’t be doing that. I would say, just try not to use more inotify watches than you need to, and don’t worry about it unless you notice a significant decrease in performance.
[[email protected] ~]# cat /var/log/lsyncd.status | grep Inotify Inotify watching 293208 directories [[email protected] ~]# cat /proc/sys/fs/inotify/max_user_watches 1048576
lsyncd uses about 130M of memory.
I use lsyncd to keep some directories in sync with the disaster recovery server.
No performance hit/penalty on the main server.
100 billions trillions gazillions would be too many, probably. Kernel Korner – Intro to inotify mentions “thousands of watches” so at least that number should not be a problem.