Как я могу диагностировать причину значительно более медленного времени, необходимого для завершения "поиска файлов по строке" при использовании Zend Studio?

Question

Я часто использую функцию Search в программном обеспечении Zend Studio (которое построено поверх Eclipse). Я использую это много. Вероятно, 10-100 раз в день.

Я испытал таинственное разнообразие во времени поиска, когда я использовал Поиск, чтобы найти строку в одном из файлов внутри Проекта. Часто это занимает всего секунду, чтобы завершить поисковый запрос. Но иногда это занимает 10-20 секунд, и это проблема, которую я пытаюсь решить / диагностировать.

Что я делаю:

• нажмите Ctrl-H (открывает меню поиска)
• введите строку поиска
• нажмите Поиск
• обычно это занимает около 1 секунды или меньше, но иногда это занимает 10-20 секунд [и это проблема]

Что я вижу

Это происходит спорадически, не всегда, но, тем не менее, часто.

Что я пробовал:

я пытался

• ограничение Working Set конкретными подпапками
• Ограниченные File name patterns для определенных расширений файлов
• Дефрагментировал мой диск
• Антивирус не сканирует
• Использование такого инструмента, как Process Monitor , не собирает много информации. то есть в прошлый раз, когда я поймал это, я думаю, что svchost кажется, делал много запросов на чтение файла, но это не говорило мне много.

Вопрос

Как я могу диагностировать причину замедления поиска?

Статистика

5461 файлов, 352 папки 139Mb общего размера файлов на диске

Обновление по использованию Process Monitor

Я запускал поиск с помощью ProcMon дважды - в первый раз это было медленно, а во второй раз - быстро. Первый поиск длился 40 секунд, он же медленный. Второй поиск длился 1,8 секунды, он же быстрый. Медленный поиск повторяется в первый раз, после того как я некоторое время не использую поиск, а затем снова запускается быстро.

Я запустил diff для событий медленного и быстрого поиска, и среди всех CreateFile, QueryDirectory, Close File, ReadFile, QueryStandardInformationFile для обоих запусков разница между двумя запусками составляла - дополнительные 2649 строк для медленного, примерно так:

Process Name: ZendStudio.exe
Operation: ReadFile
Path: jpgraph\src\jpgraph_plotband.php
Result: SUCCESS
Detail: Offset: 0, Length: 8,192, I/O Flags: Non-cached, Paging I/O, Priority: Normal

Мое предположение о причине медленного поиска

Я предполагаю, что в первый раз файлы, возможно, действительно читаются, но во второй раз они где-то полностью кэшируются, и поэтому существует разница в скорости. Я полагаю, что на чтение всех файлов в первый раз уходит около 40 секунд, и всего 2 секунды, чтобы снова просмотреть их полностью, когда они кэшируются.

В этом смысле кеширование объясняет эту невероятную разницу в скорости. Однако мне стало интересно, есть ли у меня медленный, старый или сильно фрагментированный диск для поиска, занимающего 40 секунд, поскольку я не могу представить, что время медленного поиска находится в пределах приемлемой нормы.

Answer 1

Деннис

В прошлом у меня была такая же проблема, как у вас, и я использовал Process Monitor от Sysinternals для диагностики своей проблемы. Так как это программное обеспечение показывает все, что происходит "под капотом" в Windows, возможно, оно может вам помочь.

Это довольно сложно найти решение, но это может помочь, если у вас есть терпение и правильно установить фильтры в Procmon. Вам нужно установить фильтр для вашего процесса (вашего исполняемого образа), чтобы он захватывал только то, что делает ваше программное обеспечение.

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