0

I have a server where my app is using FileSystemWatcher to monitor a folder say, e:\A. Inside the folder A, there are as many as 16,000 folders and each subfolder has numerous other folders and files.

The app is crashing to desktop in about 1 hour. When there were fewer folders, the app was working fine. I have increased the internal buffer to twice the default value.

Is there a limit on the maximum number of folders to be monitored? Or the folder itself is unstable due to the huge number of folders?

Update: The app runs on a virtual machine(vmware).
Windows Server 2008.
dual 2.53 Intel Xeon.
4 GB of RAM.
RAID. [ 1.3TB, may be increased. ]

max_force
  • 769
  • 6
  • 12
  • "Crashing" = Throwing an exception? Just disappearing into the ether? Something else? – lc. Nov 06 '12 at 18:39
  • 3
    this will help you understand better why: http://stackoverflow.com/questions/10195317/what-are-practical-limits-on-the-number-of-filesystemwatcher-instances-a-server – Hardrada Nov 06 '12 at 20:17
  • @lc. its one of those APPCRASH thing where is says "The app has stopped working" and you get to select whether to check an online solution or to close the window. – max_force Nov 06 '12 at 22:33
  • @Hardrada: thanks for pointing that out. If I have to send something to the gallows, I'd send Paged/Non-paged Pools. Still not sure.. – max_force Nov 06 '12 at 22:33
  • Certainly, you don't want one FSW watching all that you have. Trim it down by either having more FSW's (1 per folder? 1 per set of folders?). Don't watch sub folders and only listen for events that you need to. I am doing something similar to this and short of writing a File System Driver, this is working out for me with a low mem foot print. But the FSW can be bitchy with network drops on UNC's. – Hardrada Nov 07 '12 at 01:06

0 Answers0