Случай Медленного Файла Проекта Открывается

Случай открылся, когда клиент, администратор сети, поддержка Microsoft, с которой связываются, потому что пользователь, о котором сообщают, о котором файлы Microsoft Project, расположенные на сетевой доле, занимали до минуты, чтобы открыться и однажды каждые 10 раз открытое, привел к ошибке, показанной в рисунке 17-19.

Рис. 17-19. Ошибка, которая произошла на файле Проекта, открывает одно время в 10.

Администратор, проверенный проблема и проверенные сетевые настройки и задержка к файловому серверу, но он не мог найти ничего, что объяснит проблему. ­Инженер службы поддержки Microsoft ­присваивался к случаю, который спрашивают администратора, чтобы получить трассировки Procmon и Network Monitor медленного открытого файла. После получения журналов немного позже, он открыл журнал Procmon и установил фильтр, чтобы включать только операции, выпущенные процессом Проекта и затем другим фильтром, чтобы включать пути, которые ссылались на долю конечного файла. Сводное диалоговое окно Файла, которое он открыл из меню Tools Прокмона, показало существенное время, проведенное в операциях файла, получающих доступ к файлам на доле, показанной в столбце File Time в рисунке 17-20.

К файлам получают доступ во время трассировки.

Рис. 17-20. Сводное время показа диалогового окна файла, проведенное в операциях файла (затененное доменное имя).

 

Пути в трассировке, показанной, что профили пользователя были сохранены на файловом сервере и что запуск Проекта вызванный тяжелый доступ подкаталога AppData профиля. Если многим ­пользователям сохранили их профили на том же самом сервере через перенаправление папки и запускали ­подобные приложения, которые использовали хранившие данные в AppData, который, конечно, учтет, по крайней мере, некоторые из задержек, пользователь испытывал. Известно, что перенаправление ­каталога AppData ­может закончиться ihbn проблемы производительности, столь основанные на этом, инженер службы поддержки, достигнутый его первая рекомендация: для компании, чтобы сконфигурировать ее профили пользователя роуминга, чтобы не ­перенаправить AppData и синхронизировать каталог AppData только при входе в систему и выходе из системы на руководство, найденное в этом блоге post2 Microsoft:

Специальные соображения для папки AppData\Roaming:

Если папка AppData перенаправляется, некоторые приложения могут испытать проблемы производительности, потому что они будут получать доступ к этой папке по сети. Если это так, рекомендуется, чтобы Вы сконфигурировали следующую установку Group Policy, чтобы синхронизировать папку AppData\Roaming только при входе в систему и выйти из системы и использовать локальный кэш, в то время как пользователь зарегистрирован. В то время как это может оказать влияние на скорости входа в систему/выхода из системы, пользовательский опыт может быть лучше, так как приложения не будут замораживаться из-за сетевой задержки.

Пользовательская конфигурация> Административные Шаблоны> Система> Профили пользователя> каталоги Network, чтобы синхронизировать при Входе в систему/Выходе из системы.

Если приложения продолжают испытывать проблемы, следует рассмотреть, исключая AppData от Перенаправления Папки - нижняя сторона выполнения так - то, что это может увеличить Ваше время входа в систему/выхода из системы.

Затем, инженер, исследованный трассировка, чтобы видеть, был ли Проект ответственен за весь трафик к файлам, таким как Глобальная переменная. MPT или если дополнение было ответственно. Это - то, где трассировка стека была indispensible. После устанавливания фильтра, чтобы показать только доступы к Глобальной переменной. MPT, файл, который учитывал большую часть времени ввода-вывода как показано сводным диалоговым окном, он заметил, что это было открыто и было считано многократно. Во-первых, он видел пять или шесть долгих выполнений маленьких, случайных чтений. (См. рисунок 17-21.)

Рис. 17-21. Долгие выполнения маленьких, случайных чтений по сети.

 

² Профиля пользователя на Windows Server 2008 Служб Удаленного рабочего стола R2, http://blogs.msdn.com/b/rds/ archive/2009/06/02/user-profiles-on-windows-server-2008-r2-remote-desktop-services.aspx

 

Стеки для этих операций показали, что сам проект был ответственен, как бы то ни было. В рисунке 17-22 структурируйте 25 шоу, WINPROJ.EXE вызывающих код в Ole32.dll, который в конечном счете вызывает в Kernel32.dll (структурируйте 15), который вызывает API ReadFile в Kernelbase.dll — все из которых являются DLL Windows.

 Рис. 17-22. Winproj.exe вызывает код Windows, чтобы считать файл.

Он также видел последовательности больших, некэшируемых чтений. (См. рисунок 17-23.) Маленькие чтения, он смотрел сначала, кэшировались, таким образом не будет никакого сетевого доступа после первого чтения, вызванного данные, чтобы кэшироваться локально. Но некэшируемые чтения пошли бы в сервер каждый раз, делая их намного более вероятно, чтобы воздействовать на производительность.

 

Рис. 17-23. Последовательности больших, некэшируемых перечитывают по сети.

 

Чтобы усугубить положение, он видел, что тот же самый файл был перечитан по сети многократно в трассировке. Трассировка, показанная в рисунке 17-24, фильтруется, чтобы показать начальные чтения файла, где смещение файла в столбце Detail устанавливается в 0.

Рис. 17-24. Файлы, перечитываемые по сети; смещение файла 0 указывает на чтение с начала файла.

Стеки для этих чтений, показанных их, чтобы быть результатом стороннего драйвера, SRTSP64. SYS. Первая подсказка, что это - сторонний драйвер, видима во фреймах 18-21 в диалоговом окне трассировки стека, показанном в рисунке 17-25. С Procmon, сконфигурированным, чтобы получить символы из серверов символа Microsoft, SRTSP64. SYS не имеет никакой информации о символе и вызывает FltReadFile (структурируйте 17).

Рис. 17-25. SRTSP64.SYS в стеках вызова начальных чтений файла.

Далее, стековые фреймы выше тот же самый стек (показанный в рисунке 17-26) показали что последовательность SRTSP64. Чтения SYS выполнялись в пределах контекста менеджера по фильтру обратные вызовы (структурируйте 31), выполняемый, когда Проект, открытый файл с CreateFileW, вызывают во фрейме 50. Это поведение характерно для антивирусных сканеров для проверки на вирусы при попытке доступа.

 Рис. 17-26. Файл, открытый обозначенный CreateFileW во фрейме 50 результатов в файле, читает из SRTSP64. SYS.

Конечно же, дважды щелкая по одному из SRTSP64. Строки SYS в стеке, выведенном на экран свойства модуля. Диалоговое окно, показанное в рисунке 17-27, подтвержденном, что это был Symantec AutoProtect, который неоднократно выполнял обнаружение вирусов на доступе каждый раз Проект, открытый файл с определенными параметрами.

 

Рис. 17-27. Диалоговое окно Свойств модуля для SRTSP64. SYS.

Как правило, администраторы конфигурируют антивирус на файловых серверах, таким образом нет никакой потребности в клиентах отсканировать файлы, на которые они ссылаются на серверах, потому что сторона клиента, сканирующая просто, приводит к сканированиям duplicative. Это привело к второй рекомендации инженера службы поддержки, которая была для ­администратора, чтобы установить фильтр исключения на их клиентском развертывании антивируса для профилей пользователя хостинга доли файла.

Меньше чем через 15 минут инженер описал свой анализ и рекомендации и отослал их назад к клиенту. Сетевая трассировка монитора просто служила подтверждением того, что он наблюдал в трассировке Procmon. Администратор продолжил, чтобы реализовать ­предложения и, несколько дней спустя, подтвердил, что пользователь больше не испытывал долгие загрузки файла, ни ошибки, о которых он сообщил. Другой случай, с которым соглашаются Procmon и стеки потока.