Чтобы рекурсивно просматривать мой домашний каталог и все подкаталоги в течение 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часов?
Я спрашиваю и о конкретных, и о асимптотических сложностях (я еще не разбирался, какие структуры данных, в каких частях стека ядра и как подключаются в качестве реализации inotify).
Я имею в виду: вычислительные затраты, затраты памяти и другие затраты.
Я предполагаю, что это будут функции (дающие конкретные числа в КиБ или оценки загрузки процессора (возможно, есть какие-то хорошие тесты), или даже асимптотические (например, «each io»):
- просматриваемые файлы/каталоги
- операции над файлами/каталогами выполнены
- длины очередей часов inotify
но может я что-то упустил?
Я пока не углублялся в архитектуру, но мне интересно, влияет ли это на операции с неотслеживаемыми инодами/каталогами/файлами/путями?
Аналогично, чем это отличается для fanotify?
решение1
Я не использую inotifywatch, я использую gidget, поэтому мой ответ не относится конкретно к этому инструменту, это просто, надеюсь, полезное замечание об inotify (которое ятяжелоиспользовать).
Каждый inotify watch использует 540 байт памяти ядра на 32-битных архитектурах и 1080 байт на 64-битных архитектурах. Память ядра не подлежит свопингу. Так что, конечно, есть затраты памяти.
Но по моему опыту, не количество часов замедляет работу — ядро проверяет их быстро. Что, как правило, влияет на производительность системы, в реальном использовании, так это то, что вы делаете, когда срабатывают события inotify. Если у вас есть (например) от десяти до сорока тысяч файлов 835, соответствующих HIPAA, которые поступают со скоростью провода по гигабитному или десятигигабитному каналу, пользовательские процессы, запускаемые для обработки каждого из них, будут нагружать систему гораздо сильнее, чем сам inotify.
Но чтобы ответить хотя бы на один из ваших вопросов: нет, установка наблюдения не будет иметь никакого эффекта/затрат для неотслеживаемых файлов или папок. Ядровсегдапроверяет, установлено ли наблюдение, и проверка займет столько же времени и ресурсов, сколько бы его ни было, независимо от того, сколько других объектов файловой системы отслеживается. Но опять же, если вы постоянно генерируете огромное количество процессов (по любой причине), это определенно повлияет на общую производительность системы.
Кроме того, вы упомянули, что используемый вами инструмент может рекурсивно следить за папками и подпапками. Это не то, что делает inotify, это то, что делает ваш инструмент. Вероятно, он сканирует папку, которую вы выбрали, на наличие подпапок, устанавливает наблюдения для всех из них, а затем срабатывает всякий раз, когда создается новый, чтобы установить еще одно наблюдение. Так что у вас есть некоторая накладная деятельность, которая только косвенно связана с системой inotify, и ее влияние на производительность будет в основном связано с поведением инструмента, а не с поведением inotify. Если инструмент неряшливый и неэффективный в плане ресурсов (я не знаю, но я сомневаюсь в этом, поскольку инструменты inotify обычно пишутся на C), это может быть проблемой.