Кто-то подвешивает систему в Kernel Times

[Aleck D.Shadow]

Ситуация следующая:
Работают программки, загрузка всех 2х процессоров обычно не более 10%,
апериодично возникает процессорное голодание, Task Manager подсказывает, что в момент голодания, возврастает Priveleged time
Нашел утилитку Kernrate from MS.
Она мне говорит, что в момент нехватки ресурсов возрастает нагрузка на модуль HAL а именно функции
HalReadDmaCounter
С чем это может быть связано?
Как в принципе вычислить узкое место в режиме ядра?

[Ochkarik]

что вы подразумеваете под процессорным голоданием? кто голодает то? как долго? сколько он вообще ест обычно?)

а вычисляется обычно на глазок) мною по крайней мере. уж если я пишу что то, то четко представляю кто что вызывает и сколько раз... в моем коде.

[Aleck D.Shadow]

все программы в user mode подвисают на ~3 секунды затем все восстанавливается. В это время Task Manager показывает что процессоры заняты в Priveleged time. Вот я и думал как узнать - что бы это могло быть.

[Ochkarik]

а в чьем процессе? системный? или произвольный?

[Aleck D.Shadow]

а в чьем процессе? системный? или произвольный?

Произвольный.

[Ochkarik]

произвольный - значит это либо DPC либо ISR. HalReadDmaCounter - чтение счетчика переданных через DMA данных. следовательно кто то производит кривое ожидание окончания DMA транзакции. DMA транзакцию могут использовать диски, видео, звук, либо какие нибудь контроллеры.. (можно попробовать поотключать по очереди)

вобще 3 секунды это не то чтобы много - это ОЧЕНЬ много.
я бы отлаживался софтайсом. ждал бы этой паузы(3 сек можно с клавиатуры поймать). в момент загрузки проца - вызывал бы софтайс и ставил бы брякпоинт на эту функцию. потом поймал бы ее, и попытался бы выяснил ISR это или DPC или APC или IOCTL? (анализируя стек взовов) потом смотрел чъи это ISR/DPC или что то еще.
если ISR то можно сразу объект найти и следовательно девайс.
если DPC - владельца можно найти по входным параметрам(DpcForIsr объект), в крайнем случае (если CustomDpc) отследить по адресу этих параметров - кто выделял область памяти для этих переменных. кто еще обращается к ним же. на крайний случай пошаговой отладкой.
это все подходит для случая если можно с клавиатуры момент отловить. и если он достаточно часто происходит.
как-то так...

PS был еще ключик в настройках системы - "оптимизировать выполнение программ или севрисов" это свойства компа-быстродействие. посмотрите как он стоит. может это как раз разница между 1 сек и 3 сек будет. хотя вряд ли.

[Ochkarik]

хм. я вчерась немного погорячился наверное.
вопрос про процесс был вот в связи с чем:
жрать ресурсы производительности может системная нить, либо нить драйвера. либо другой вариант - тормозить могут DPC (которые могут выполнятся в контексте произвольного процесса, независимо от того кто их выставляет). поэтому важно для начала определить - нить это или DPC? кроме того во время выполнения DPC переключение задач не происходит. оно может происходить только между выполнением DPC.
таким образом - если ресурсы съедает конкретная нить(процесс) - это одно....
попробуйте посмотреть вот еще какую штуку. запустите счетчики производительности системы - там есть возможность просмотреть раздельно - загрузку по каждому процессу в системе (объект процесс). это раз.
и второе - там же посмотрите на очереди DPC и прерывания - (объект процессор).

[Aleck D.Shadow]

проблему нашел - всё дело в "волшебных пузырьках"  , а точнее в Windows File Cache.
Похоже что проблема возникает лавинообразно, т.к. программы которые крутятся на серваке ведут очень много журналов,
отсюда проблема с обработкой кэшем.
Вообще выглядит следующим образом:
Сначала возрастает значение счетчика (Perfomance) Physical disc -> Disc write/sec, одновременно с ним нарастает cache -> sync pin read/sec,
и спустя некоторое время (примерно 40-45 секунд) происходит зависание, т.е. возрастает время в priveleged time.
Судя по всему кэш сбрасывается на диск.
Однако не понятно почему делая в программах сброс (flush) данных на диск принудительно не помогает, решить проблему!!!
Но если воспользоваться программой sync (www.sysinternals.com), в начале этого роста то зависания не происходит.