2009-02-11 2 views
27

Я работаю над демоном, который отслеживает события файла через inotify, чтобы инициировать различные типы событий при доступе к файлам. Я прочитал, что часы немного дороже, потому что ядро ​​хранит полное имя пути для каждого просматриваемого файла.Что такое разумное количество часов inotify с Linux?

Сколько часов будет слишком много?

Редактировать: В основном, мне интересно. Вы когда-нибудь видели заметное поражение в производительности, если да, то сколько часов прошло? Да, я должен контролировать/рекурсивно (однако его минимальная загрузочная система).

ответ

17

AFAIK Ядро не хранит путь, а inode. Тем не менее, есть 540 байт на Watch в 32-битной системе. Двойной размер на 64 бит.

Я знаю из Lsyncd (может быть, вы хотите проверить это?) Люди, у которых есть миллион часов. Он просто ест гигабайт памяти.

6

100 миллиардов триллионов gazillions было бы слишком много, возможно. Kernel Korner - Intro to inotify упоминает «тысячи часов», поэтому по крайней мере это число не должно быть проблемой.

23

Вы можете найти системные ограничения, прочитав /proc/sys/fs/inotify/max_user_instances (максимальное количество инотифицирующих объектов) и /proc/sys/fs/inotify/max_user_watches (максимальное количество просмотренных файлов), поэтому, если вы превысите эти цифры, их слишком много ;-) Максимальное количество часов обычно составляет несколько десятков тысяч или более - в моей системе, 262143 - что, вероятно, больше, чем вам когда-либо понадобилось, если вы не пытаетесь смотреть каждый файл в файловой системе, но вы не должны этого делать. Я бы сказал, просто постарайтесь не использовать больше inotify часов, чем вам нужно, и не беспокойтесь об этом, если не заметите значительного снижения производительности.

+1

Почему я не должен использовать inotify для просмотра всей файловой системы? можете ли вы быть конкретными? – Blub

+0

@Blub хорошо, почему вы хотите это сделать? Если вы не отлаживаете реализацию файловой системы, я не могу придумать хороший вариант использования, и если это то, что вы делаете, вероятно, лучше подключиться к самому файловому файлу. Не говоря уже о том, что inotify, вероятно, не будет иметь достаточно часов, чтобы фактически наблюдать за _everything_ в файловой системе с современной ОС. Но я думаю, что если это произойдет (т. Е. Если вы работаете с уменьшенным набором файлов), это, вероятно, не самое худшее. Пока ваш компьютер может справиться с этим, он не повредит ничего AFAIK. –

+2

Я хочу индексировать том, и поэтому, если файл меняется в любом месте, мне нужно обновить свой индекс. я действительно посмотрел на исходный код ext4, это не совсем сделано для пользовательских добавлений .. есть только утилита dumpe2fs, которая может печатать «блоки», но пока не знаю, как получить фактические пути оттуда. И все же ... Мне нужно будет постоянно запускать эту утилиту, по крайней мере, один раз в секунду, чтобы повторно проиндексировать индекс. Не совсем здорово, я бы предпочел вернуть какое-то событие - например, inotify. – Blub

9

Моя информация:

[[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 использует около 130M памяти.

Я использую lsyncd, чтобы синхронизировать некоторые каталоги с сервером аварийного восстановления.

Отсутствие производительности/штраф на главном сервере.

+4

Я думаю, что вы видите использование памяти lsyncd, а не inotify ...inotify использует память пространства ядра ... – confiq

 Смежные вопросы

  • Нет связанных вопросов^_^