Вопрос по performance, filesystemwatcher, .net – System.IO.FileSystemWatcher для мониторинга папки сетевого сервера - Вопросы производительности

39

Я хочу посмотреть дерево папок на сетевом сервере на предмет изменений. Все файлы имеют определенное расширение. В дереве около 200 папок и около 1200 файлов с расширением, которое я наблюдаю.

Я могу't написать сервис для запуска на сервере (запрещено!), поэтому решение должно быть локальным для клиента. Своевременность не особенно важна. Я могу жить с минутой или более задержкой в уведомлениях. Я наблюдаю за созданием, удалением, переименованием и изменениями.

Будет ли использование .NET System.IO.fileSystemWatcher создавать большую нагрузку на сервер?

Как насчет 10 отдельных наблюдателей, чтобы сократить количество просматриваемых папок / файлов? (до 200 из 700 папок, до 1200 из 5500 файлов) Больше сетевого трафика вместо меньшего? Мои мысли - перестановка на сервере, чтобы поместить просматриваемые файлы под одно дерево. Я не всегда могу иметь эту опцию, поэтому команда наблюдателей.

Я полагаю, что другое решение - это периодическая проверка, создает ли FSW чрезмерную нагрузку на сервер или нет.работать по целому ряду причин типа SysAdmin.

Есть лучший способ сделать это?

Ваш Ответ

7   ответов
9

да я впервые их использовал, у меня возникли проблемы с прекращением их работы, в основном из-за того, что я обрабатывал изменения в потоке, который сообщил об этом изменении.

Однако теперь я просто помещаю изменения в очередь и обрабатываю очередь в другом потоке. Это, кажется, решает проблему, которую я первоначально имел. Для вашей проблемы, вы могли бы иметь несколько наблюдателей, выдвигающих одну и ту же очередь.

Тем не менее, я неЯ использовал это с вашей проблемой.

1

на объекте watcher. Я'Мы проверили тысячи обновлений файлов, ни один не потерян.

Я рекомендую использовать многопоточный подход - триггер, являющийся средством просмотра файлов. Он может запустить поток для каждого обнаруженного изменения файла. Наблюдатель может обрабатывать намного быстрее с меньшей вероятностью переполнения. (используйте асинхронный поток)

Он может выглядеть на 100% надежным в локальной файловой системе, но он ужасно ненадежен в общем сетевом ресурсе. Если файловый сервер, обслуживающий общий ресурс, получает отказ, FSW теряет сознание. DSoa
-1

что тамs любого рода активное состояние или связь между компьютером с FSW и компьютером, местоположение которого контролируется. Другими словами, ЖСБ неt проверить сетевую ОС, чтобы проверить файл.

Можно представить, что сообщение или событиетолько поднял / отправил сетевому FSW при изменении.

Но это всего лишь домыслы. :)

Как клиент узнает, что на сервере что-то изменилось, если быпинг это? AFAIK ЖСБ неЗапустить любые процессы на сервере. Тем не менее, AFIK немного в этом случае. CAD bloke
Теперь у нас есть ответ, но чтобы ответить на ваш вопрос: ЖКС отправит запрос на компьютер, чтобы онЯ хотел бы получать уведомления при изменении файла. Ты нене спрашивайте журнал, есть ли у него новый номер, вы подписываетесь один раз, и они отправляют новые номера, когда онипереиздан. core
3

FSW не создает большой сетевой трафик. Однако, если есть проблема с производительностью, ваш подход использования нескольких наблюдателей и разбивки его на меньшее количество папок, которые вы просматриваете, звучит разумно.

У меня были большие проблемы с FSW на сетевых дисках: удаление файла всегда вызывало событие ошибки, а не удаление. Я не нашел решения, поэтому я теперь избегаю использования FSW, если есть способ обойти это ...

2

MSDN документация указывает что вы можете использовать компонент FileSystemWatcher для отслеживания изменений файловой системы в сетипривод.

Это также указывает на то, что компонент-наблюдатель прослушивает уведомления об изменениях файловой системы, а не периодически запрашивает изменения на целевом диске.

Исходя из этого, объем сетевого трафика полностью зависит от того, насколько вы ожидаете, что содержимое этого сетевого диска изменится. Компонент FSW не увеличит уровень сетевого трафика.

69

IO.FileSystemWatcher для удаленных уведомлений об изменениях в описываемом вами сценарии, вероятно, самый эффективный метод. Он используетFindFirstChangeNotification а такжеReadDirectoryChangesW Win32 API функционирует внутренне, что, в свою очередь, оптимизирует связь с сетевым перенаправителем (при условии, что стандартная сеть Windows: если используется сторонний редиректор,не поддерживает необходимую функциональность, вещи выиграютне работает вообще). Оболочка .NET также использует асинхронный ввод-вывод и все остальное, еще больше обеспечивая максимальную эффективность.

Единственная проблема с этим решением заключается в том, чтоне очень надежный. Кроме необходимости иметь дело с сетевыми подключениями, которые временно исчезают (что неЭто слишком большая проблема, так как IO.FileSystemWatcher вызовет событие ошибки в этом случае, которое вы можете обработать), базовый механизм имеет определенные фундаментальные ограничения. Из документации MSDN для функций Win32 API:

ReadDirectoryChangesW происходит сбой ERROR_INVALID_PARAMETER, когда длина буфера превышает 64 КБ, и приложение отслеживает каталог по сети. Это связано с ограничением размера пакета базовыми протоколами обмена файлами.

Уведомления не могут быть возвращены при звонкеFindFirstChangeNotification для удаленной файловой системы

Другими словами: при высокой нагрузке (когда вам потребуется большой буфер) или, что еще хуже, при случайных неуказанных обстоятельствах вы можете не получить ожидаемые уведомления. Это даже проблема с локальными наблюдателями файловой системы, но этогораздо больше проблем по сети.Еще один вопрос здесь на SO более подробно описывает присущие API проблемы с надежностью.

При использовании наблюдателей файловой системы ваше приложение должно справляться с этими ограничениями. Например:

Если файлы, которые выищите иметь порядковые номера, сохраните последний порядковый номер, о котором вы получили уведомление, чтобы вы могли искать 'пробелы будущих уведомлений и обработки файлов, для которых вы не сделалиполучить уведомление;

При получении уведомления всегда выполняйте полное сканирование каталогов. Это может звучать очень плохо, но так как сканирование основано на событиях, оно 'Все еще гораздо эффективнее, чем тупой опрос. Кроме того, до тех пор, пока вы храните общее количество файлов в одном каталоге, а также количество сканируемых каталогов, менее тысячи или около того, влияние этой операции на производительность в любом случае должно быть довольно минимальным.

Настройка нескольких слушателей - это то, чего вам следует избегать, насколько это возможно: во всяком случае, это сделает вещи дажеМеньше надежный ...

Во всяком случае, если вы абсолютноиметь использовать наблюдателей файловой системы, все может работать нормально, если выосознавать ограничения и неОжидайте уведомления 1: 1 для каждого файла, измененного / созданного.

Итак, если у вас есть другие варианты (по сути, если процесс записи файлов уведомляет вас не на основе файловой системы: любой обычный метод RPC будет улучшением ...), то это определенно стоит рассмотреть с точки зрения надежности. зрения. Я '

1

ремени. Он недостаточно стабилен для обработки событий, которые происходят слишком быстро. Для обеспечения 100% чтения файлов. Я использую простые методы каталогов для поиска по файлам. Прочитав его, сразу скопируйте файлы в другую папку. Чтобы изолировать его от новых файлов, добавляемых во время чтения файлов.

Таймер используется для регулярного чтения папки. Скопировав уже прочитанный файл в папку архива, убедитесь, что он больше не будет прочитан. Последующее чтение всегда будет новыми файлами.

var fileNames = Directory.GetFiles (srcFolder); foreach (строка fileName в fileNames) {string [] lines = File.ReadAllLines (fileName);

Похожие вопросы