¿Cuáles son los límites prácticos sobre el número de instancias de FileSystemWatcher que puede manejar un servidor?

Question

Tengo un servicio de Windows que actualmente está instanciando alrededor de una docena de instancias de FileSystemWatcher para supervisar las carpetas compartidas en la red corporativa para que se procesen los archivos.

Estoy buscando 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 en el número de instancias FileSystemWatcher que un sistema de producción puede manejar de manera confiable?

Editar: En mi caso, la propiedad InternalBufferSize no se modifica por lo que el InternalBufferSize es el valor predeterminado de 8 KB ... supongo que el aumento de InternalBufferSize afectaría el número de casos FileSystemWatcher un sistema puede funcionar simultanesouly por lo que también es una parte de la ecuación ...

Editar: Si crees 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, comparte tu experiencia o enlaces a la documentación o artículos que corroboran tu opinión ... Realmente me gustaría saber de alguien que alcanzó el límite en la producción, independientemente de sus especificaciones de hardware, por favor antes de votar para considerar a otras 7 personas en menos de 20 minutos ha mostrado interés en escuchar a alguien que ha excedido los límites ...

Answer 1

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

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

Eso es los dos recursos del sistema operativo para tener en cuenta, el mango creado por la llamada a CreateFile por FileSystemWatcher, y el tamaño del búfer (por defecto) de 8 KB en el núcleo para cada objeto FileSystemWatcher que quita del kernel paginado y ninguno de su sistema Piscinas de papel.

Sus FileSystemWatcher s compiten esencialmente por estos tres recursos.

1. CPU tiempo para procesar los cambios
2. Mangos en el sistema
3. Página piscina

Es poco probable que golpear a un problema con (2). Es probable que se produzca un problema con (3) en un sistema de alimentación (cargas de CPU) que ejecute x86. De lo contrario (1) será su límite.

Maneja

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 16 millones + mangos (incluso en x86) antes de ejecutar fuera, para sus intententions, I' pensar en ello como un recurso infinito. Va a agotar los cambios de procesamiento de la CPU mucho antes de llegar a cualquier límite del sistema operativo.

Página/Piscinas-no paginados

Página/piscinas no paginado se puede ver en el administrador de tareas. En x86 son muy finito. Más aquí, http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#memory_limits

CPU

Vas a ver un montón de evidencia anecdótica de que cuando este se agota, FileSystemWatcher especie de deja de funcionar. Algunos cambios en el directorio se informan, otros no, e inevitables en las implementaciones grandes de FileSystemWatcher que terminan teniendo que detectar estas ocasiones y hacer un directorio que se enumera a sí mismo, o hacerlo en una base de votación.

Notas

Si va a implementar una carga de FileSystemWatcher s cuidado con;

1. Buffer sobre corre
2. tamaño Buffer mayor que 64 KB en 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