Even though there are only 16 FileSystemWatcher instances, there is over 13,000 of these System.IO.FileSystemWatcher+AsyncReadState. One of these AsyncReadState is created (only) when FileSystemWatcher's StartRaisingEvents is called - this "count" here is implying a very large number of calls to that even for a small limited number of watchers.
Each one of these byte arrays is pinned (it has to be for overlapped operation) and this is causing fragmentation (that eventually leads to creation of Free blocks). It is not clear why there are 13,000 of those AsyncReadState for file change monitoring.. The byte array is part of this AsyncReadState and acts as its buffer."
System.IO.FileSystemWatcher+AsyncReadState
Has anyone else had an issue with System.IO.FileSystemWatcher+AsyncReadState causing a memory leak?
Azure Support have advised:
"It appears that at least part of that fragmentation is coming from internal byte arrays that are used by FileSystemWatcher:
HandleTable: 000001be583ea1f8 (strong handle) -> 01af3a06fa10 System.Threading.ThreadPoolBoundHandleOverlapped -> 01af3a06f990 System.IO.FileSystemWatcher+AsyncReadState -> 01b0ceef5c40 System.Byte[]
Even though there are only 16 FileSystemWatcher instances, there is over 13,000 of these System.IO.FileSystemWatcher+AsyncReadState. One of these AsyncReadState is created (only) when FileSystemWatcher's StartRaisingEvents is called - this "count" here is implying a very large number of calls to that even for a small limited number of watchers.
Each one of these byte arrays is pinned (it has to be for overlapped operation) and this is causing fragmentation (that eventually leads to creation of Free blocks). It is not clear why there are 13,000 of those AsyncReadState for file change monitoring.. The byte array is part of this AsyncReadState and acts as its buffer."
If so - any ideas how to resolve it?
is working on a reply...