Quali sono i limiti pratici al numero di istanze FileSystemWatcher un server in grado di gestire?

Question

Ho un servizio di Windows che è attualmente in un'istanza di circa una dozzina FileSystemWatcher casi per monitorare cartelle condivise attraverso la rete aziendale per i file da elaborare.

Sto cercando di aggiungere più istanze quindi mi chiedo se qualcuno qui ha esperienza (con sistemi di produzione) su quali sono i limiti pratici sul numero di istanze di FileSystemWatcher che un sistema di produzione può gestire in modo affidabile?

Edit: Nel mio caso, la proprietà InternalBufferSize non viene modificato in modo che l'InternalBufferSize è il default 8 KB ... Suppongo che l'aumento avrebbe InternalBufferSize influisce sul numero di casi FileSystemWatcher un sistema può funzionare simultanesouly in modo che sia anche una parte dell'equazione ...

Modifica: Se si pensa che questo è esclusivamente un problema di risorse e dipende solo dalla quantità di memoria disponibile o da qualche altro aspetto hardware del sistema, si prega di condividere la propria esperienza o collegamenti alla documentazione o articoli che corroborano la tua opinione ... mi piacerebbe davvero sentire da qualcuno che ha raggiunto il limite della produzione, indipendentemente dalla loro specifiche hardware quindi per favore prima di votare per chiudere considerare che altre 7 persone a meno di 20 minuti ho mostrato interesse a sentire da qualcuno che ha spinto i limiti su questo ...

Answer 1

FileSystemWatcher sotto la copertura utilizza ReadDirectoryChangesWhttp://msdn.microsoft.com/en-us/library/windows/desktop/aa365465(v=vs.85).aspx. Questa è un'operazione ragionevolmente economica che è solo una lettura dalla directory che completa una modifica.

I risultati vengono memorizzati in un buffer del kernel prima di essere copiati nel proprio buffer di memoria di FileSystemWatcher.

Ecco le due risorse del sistema operativo di prendere in considerazione, la maniglia creato dalla chiamata a CreateFile da FileSystemWatcher, e la dimensione 8 KB (di default) del buffer nel kernel per ogni oggetto FileSystemWatcher che toglie dal di sistema del kernel di paging e None -Piscine stagionali.

vostri FileSystemWatcher s sono essenzialmente in competizione per queste tre risorse.

1. CPU tempo per elaborare i cambiamenti
2. Maniglie sul sistema
3. Pagina Pool

è improbabile per colpire un problema con (2). probabilità di colpire un problema con (3) su un sistema di alimentazione (carichi di CPU) x86 esecuzione. Altrimenti (1) sarà il tuo limite.

Maniglie

maniglie sono esauribili (specialmente su x86), più su questo qui, http://blogs.technet.com/b/markrussinovich/archive/2009/09/29/3283844.aspx

Ma a 16million + maniglie (anche su x86) prima che si esaurisca, per i vostri intententions, I' d pensarlo come una risorsa infinita. Si esauriranno le modifiche di elaborazione della CPU ben prima di raggiungere qualsiasi limite del sistema operativo.

Pagina/Toto non di paging

Pagina/Toto non di paging può essere visto nel responsabile di operazione. Su x86 sono molto finito. Più qui, http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#memory_limits

CPU

vedrete carichi di prove aneddotiche che quando questo è esaurito, FileSystemWatcher sorta di smette di funzionare. Alcune modifiche alle directory vengono segnalate, altre no e inevitabili per le grandi implementazioni di FileSystemWatcher si finisce per dover rilevare queste occassioni e fare una lista di directory da soli, o farlo su basi di polling.

Note

Se stai attuazione guardare fuori un carico di FileSystemWatcher s per;

1. Buffer sopra corre
2. dimensioni del buffer maggiori di 64 KB su percorsi di rete.

Altro sulle buone pratiche di codifica per questo oggetto qui, http://bytes.com/topic/visual-basic-net/answers/536125-filesystemwatcher-across-network#post2092018