Это действительно так дорого, чтобы увеличить FileSystemWatcher.Внутренний размер буфера?
Я использую FileSystemWatcher для отслеживания изменений в папке, но как только у меня появляется более нескольких сотен изменений за короткое время, я пропускаю некоторые из них, потому что внутренний буфер переполняется. Поэтому я хочу увеличить InternalBufferSize (я знаю, что это не решит проблему, но сделает ее менее вероятной), но я вижу это предупреждение в документации :
Однако увеличение размера буфера дорого, потому что оно исходит из нестраничная память, которая не может быть заменено на диск , так что держите буфер как можно меньше.
Итак, мой вопрос: действительно ли это имеет значение? Большинство компьютеров сегодня имеют по крайней мере 1 ГБ оперативной памяти, поэтому мне кажется, что если я установлю размер буфера в 1 МБ (вместо стандартного 8 КБ), это не будет иметь большого значения, если 1 МБ не может быть заменен на диск. Или я что-то упустил? Я не очень много знаю о низкоуровневых вещах, таких как подкачанная/не подкачанная память, поэтому я не уверен, что это повлияет...
3 ответа:
Память, в которой выделяется буфер, безусловно, является ценным ресурсом. Windows не будет иметь дело с исчерпанием пула памяти хорошо, драйверы начнут отказывать случайным образом. Размер пула устанавливается динамически (но может быть изменен) и зависит от объема доступной оперативной памяти.
Размер буфера по умолчанию, который запрашивает FSW, составляет 8192 байта. Не так уж много на современных машинах. Базовая функция winapi не позволит вам запрашивать более 64 КБ. Запись в буфере равна 12 байт плюс длина пути к файлу умножить на два. Так что еще хуже дело обстоит 8192 / (12 + 260*2) = 15 уведомления до того, как закончится буфер. Это должно работать в большинстве случаев без особых проблем, если вы не контролируете весь диск или не имеете очень высокий трафик диска в каталоге, который вы наблюдаете. В этом случае просьба о большем буфере справедлива. Нет золотая формула, убедитесь, что для реализации класса filesystemwatcher.Событие ошибки, чтобы вы знали, что у вас есть буфер проблема.
В большинстве практических случаев вы должны иметь дело с событиями FSW тщательно. Они будут вызваны, пока процесс все еще имеет блокировку файла. Так что делать такие вещи, как открытие или копирование файла, хлопотно. Вы справляетесь с этим, помещая уведомления в потокобезопасную очередь и используя другой поток, чтобы попытаться получить блокировку файла, многократно, если это необходимо. Такая очередь теперь автоматически также очень хороший способ быстро очистить буфер. Единственное, что ты должен сделать. следите пока за тем, чтобы очередь не взорвалась сверх разумных пропорций, что приведет к сбою вашей программы с помощью OOM.
Рассмотрим потребительский дизайн производителя для чтения в событиях FileSystemWatcher.
Если у вас есть какие-то события FileSystemWatcher, которые вам не нужно обрабатывать, быстро отклоните их.
Или если некоторые могут обрабатывать быстрее, чем другие, у них есть отдельная коллекция, чтобы сохранить общий обратный отсчет.
Объем памяти без подкачки ограничен (обновление: современные версии Windows не имеют такого строгого ограничения, как в предыдущих версиях, и объем памяти теперь является гибким значением, зависящим от общей оперативной памяти, доступной для Windows) и очень важен для обитателей режима ядра (драйверы устройств, сама ОС). Потребление его без строгого контроля может быстро вызвать нестабильность в системе, и, что еще хуже, вы не найдете, что вызвало эту нестабильность.
Также, как показывают комментарии, значение имеет не размер буфера, а то, как быстро вы удаляете данные из буфера.
В большинстве случаев драйвер фильтра файловой системы будет работать лучше, чем FileSystemWatcher. Преимущества заключаются в том, что у вас может быть любой буфер журнала, который вам нужен (так как вы создадите его в любой памяти, которая вам нужна, и не будет ограничена нестраничной памятью), а также вы можете обрабатывать события по мере их возникновения, а не после того, как они происходят. Кроме того, вы можете фильтровать запросы с более высокой степенью детализации, чем позволяет FileSystemWatcher.