У нас есть приложение, которое отслеживает удаленные каталоги на предмет уведомлений об изменениях, используя ReadDirectoryChangesW() . Согласно документации Microsoft, каждый запрос уведомления об ожидаемых изменениях потребляет ресурс «рабочего элемента» на сервере. У меня есть тест, который отслеживает сотни каталогов на компьютере с Windows Server 2003 (32-разрядная версия). Он не работает постоянно, когда количество каталогов превышает определенное значение, около 120, и в этот момент на сервере регистрируется событие, говорящее что-то вроде:
Серверу не удалось выделить рабочий элемент 2 раза за последние 60 секунд.
Когда это происходит, соединение разрывается, и perfmon показывает, что произошла «нехватка рабочего элемента».
В некоторых статьях указано, что количество рабочих элементов можно увеличить, установив MaxWorkItems ключ реестра. Однако мне неясно, применимо ли это к Windows Server 2003. Я пробовал установить этот ключ (вместе с MaxMpxCt) на более высокие значения, порядка нескольких тысяч, и перезапуск службы сервера (а также перезагрузка). Однако perfmon всегда показывает «Доступные рабочие элементы» где-то в районе 120–160. Когда я запускаю свою тестовую программу, это число, как и ожидалось, падает, пока не достигнет нуля, не будет зафиксирована нехватка и соединение с моим клиентом будет разорвано.
У меня вопрос: могу ли я повлиять на количество доступных рабочих элементов в моей настройке, и если да, то как? И могу ли я сделать то же самое для других версий Windows, которые мы можем использовать (например, Server 2008 и т. Д.)?
Для справки, я также пробовал играть с MinFreeWorkItems, InitWorkItems, MaxRawWorkItems, и MaxCmds, все без толку.
Ссылки:
Да, это так. MS рекомендует ограничение в 8000, но это для очереди рабочих элементов. В прошлом мы увеличили это значение до 16000, но у нас быстро закончилась невыгружаемая память пула, поскольку 32-битная версия имеет жесткое ограничение в 256 МБ. У нас был MS, и они заявили, что, хотя вы можете увеличить количество рабочих элементов до 64000, технически это не очень хорошая идея, и они настоятельно рекомендовали нам ограничить его до 8000.
Другая проблема, вызванная этим, заключалась в том, что элементы, поставленные в очередь на обработку, не выполнялись. Такие вещи, как удаление файлов, сердцебиение кластера ms. У нас были экземпляры файлов, которые удалялись, но появлялись снова, поскольку рабочий элемент не был обработан.