Microsoft KB 911272 описывает условие, с которым мы столкнулись, когда нам удалось исчерпать объекты системы уведомлений об изменении файлов SMB через ASP.NET. Мы внедрили исправление, но знает ли кто-нибудь о счетчике производительности системы, за которым мы могли бы следить, чтобы избежать этой ситуации в будущем?
Я рекомендую людям, использующим объекты уведомлений об изменении файлов, запустить не замужем высокопроизводительный поток, который добавляет уведомления об изменениях в высокопроизводительную очередь памяти и НИЧЕГО не делает, даже не регистрирует. Поскольку отправка элементов в очередь должна выполняться очень быстро, очередь, в которой находится уведомление об изменении файла, составляет всего 8 КБ, поэтому ее легко переполнить. Дополнительные рабочие потоки или процессы затем отвечают за выталкивание элементов из очереди и ленивое выполнение работы в отношении этих событий изменения. Благодаря этому дизайну я могу отвечать на тысячи уведомлений об изменениях в секунду. Если мне нужно больше производительности, я просто добавляю больше рабочих потоков / процессов для обслуживания очереди. Примечание. Вам необходимо иметь опыт многопоточной разработки, включая использование или создание потоковобезопасных объектов.
Если внутренний буфер переполняется, вы можете зафиксировать это событие и отреагировать на него.
http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.error.aspx
Оказывается, для этого есть счетчик производительности: Redirector -> Current Commands.