c# - ejemplo - ¿Cuáles son los límites prácticos sobre la cantidad de instancias de FileSystemWatcher que un servidor puede manejar?

filesystemwatcher c#

Question

Tengo un servicio de Windows que actualmente crea una instancia de una docena de instancias de FileSystemWatcher para monitorear las carpetas compartidas en la red corporativa para que se procesen los archivos.

Estoy considerando agregar más instancias, así que me pregunto si alguien aquí tiene experiencia (con sistemas de producción) en cuanto a cuáles son los límites prácticos de la cantidad de instancias de FileSystemWatcher un sistema de producción puede manejar de manera confiable.

Edición: En mi caso, la propiedad InternalBufferSize no se modifica, por lo que InternalBufferSize es el valor predeterminado de 8 KB ... Supongo que el aumento en InternalBufferSize afectaría el número de instancias de FileSystemWatcher un sistema puede ejecutar simultáneamente, de modo que también es parte de la igualdad. ...

Edit: Si cree que esto es exclusivamente un problema de recursos y solo depende de la cantidad de memoria disponible o algún otro aspecto de hardware del sistema, comparta su experiencia o enlaces a documentación o artículos que corroboren su opinión ... Realmente me gustaría saber de alguien que alcanzó el límite de producción independientemente de las especificaciones de su hardware, así que antes de votar para cerrar, considere que otras 7 personas en menos de 20 minutos han mostrado interés en escuchar a alguien que presionó los límites para esto ...

Answer 1

FileSystemWatcher debajo de la cubierta utiliza ReadDirectoryChangesW http://msdn.microsoft.com/en-us/library/windows/desktop/aa365465(v=vs.85).aspx . Esta es una operación razonablemente económica que es solo una lectura del directorio que se completa con un cambio.

Los resultados se almacenan en un búfer de kernel antes de que se copien en su propio búfer de memoria de FileSystemWatcher .

Esos son los dos recursos de SO a tener en cuenta, el Handle creado por la llamada a CreateFile por FileSystemWatcher , y el tamaño del búfer (predeterminado) de 8KB en el Kernel para cada objeto FileSystemWatcher que se aleja del Kernel Paged y None-Paged de su sistema.

Sus FileSystemWatcher están esencialmente compitiendo por estos tres recursos.

1. Tiempo de CPU para procesar los cambios.
2. Asas en el sistema
3. Page Pool

Es poco probable que tenga un problema con (2). Es probable que encuentre un problema con (3) en un sistema de energía (cargas de CPU) que ejecuta x86. De lo contrario (1) será su límite.

Asas

Los mangos son agotables (especialmente en x86), más sobre esto aquí, http://blogs.technet.com/b/markrussinovich/archive/2009/09/29/3283844.aspx

Pero en 16million + manijas (incluso en x86) antes de que se acaben, por sus intenciones, lo considero como un recurso infinito. Agotará los cambios de procesamiento de la CPU mucho antes de alcanzar cualquier límite de sistema operativo.

Página / Grupos no paginados

Los grupos de páginas / no paginados se pueden ver en el administrador de tareas. En x86 son muy finitos. Más aquí, http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#memory_limits

UPC

Verá un montón de evidencia anecdótica de que cuando esto se agote, FileSystemWatcher deja de funcionar. Algunos cambios en el directorio se informan, otros no, y es inevitable que en las implementaciones grandes de FileSystemWatcher tengas que detectar estas ocasiones y hacer un listado de directorios, o hacerlo en una base de sondeo.

Notas

Si está implementando una carga de FileSystemWatcher s cuidado;

1. Buffer over run
2. Tamaño de búfer superior a 64 KB en las rutas de red.

Más sobre buenas prácticas de codificación para este objeto aquí, http://bytes.com/topic/visual-basic-net/answers/536125-filesystemwatcher-across-network#post2092018