MSBUILD (VS2010) очень медленный на некоторых машинах

У меня очень странный.

У меня около десятка компьютеров в нашем отделе разработки, которые все имеют одну и ту же проблему: сборки командной строки с использованием msbuild4.0 (VS2010) намного медленнее, чем должно быть. От 4x до 5x медленнее, чем ожидалось.

Все машины - это рабочие станции HP z400 (четырехъядерные процессоры Xeon + с гиперпотоком, 2,4 ГГц, 6 ГБ оперативной памяти)  под управлением Windows 7 Pro 64bit или ноутбуков HP Elitebook (Core-i7 4GB RAM) также на Win7 X64. Если я возьму один из тех, у кого есть ванильный factory предустановленный Win7, установите VS2010 и выполните сборку так же быстро, как ожидалось. Если я установил их с помощью стандартного программного обеспечения нашей компании, они стали на 4x5 раз медленнее в том же проекте VS.

Такое же изображение программного обеспечения компании на ноутбуках Lenovo (Core-i5) или настольных компьютерах (Core-i7) не обнаруживает заметной разницы между изображением компании и предустановленной Win7 factory. Это даже странно: если я устанавливаю VirtualBox с изображением Win7 в системе HP с этой проблемой, у виртуальной машины не возникает проблемы.

Каждый тестовый инструмент, который я пробовал, не показывает заметной разницы между изображением компании и предустановленной Win7. Изменяется только msbuild и только на машинах HP, работающих под Win7, на изображении компании.

Прежде чем спросить: я отключил все программные/фоновые процессы на изображении компании, но это не имеет никакого значения. Очевидно, что что-то не работает в фоновом режиме, которое каким-то образом взаимодействует с msbuild. Мое лучшее предположение заключается в том, что на оборудовании HP некоторые настройки меняются, что влияет на msbuild. Это не происходит на другом оборудовании. (И графический интерфейс VS2010 вообще не используется/не выполняется. Я знаю, что это может взаимодействовать с msbuild, если оба пытаются получить доступ к одному и тому же решению/файлам. Антивирус тоже не имеет никакого значения.)

Кто-нибудь знает, что может повлиять на работу msbuild? Любое предложение, независимо от того, насколько надуманный, приветствуется.

ОТВЕТЫ

Ответ 1

Отвечая на это сам, поскольку я нашел проблему. На всех компьютерах установлено программное обеспечение "Entrust Entelligent Security Provider". (Менеджер сертификатов, который использует наша компания для шифрованной обработки почты.)

.NET4 (в котором написан VS2010), а для компиляции кода .NET4 требуется большое количество проверок сертификатов, и это программное обеспечение (которое вызывается в процессе), по-видимому, имеет проблемы с многоядерными ПК. Чем больше ядер, тем медленнее становятся.

У систем Core-i5 есть проблема, но это не так. Они все еще пригодны для использования. Система i7 и Xeon (8 ядер) замедляется до такой степени, что становится практически непригодной.

К сожалению, я не могу избавиться от этого программного обеспечения Entrust. Это часть программного обеспечения, установленного компанией. Я просто надеюсь, что у поставщика есть решение для этого.

EDIT: проблема решена с версии 10 Entrust Entelligence. Он не устанавливается по умолчанию в качестве первого обработчика сертификата в системе.
На v9 требуется ручное редактирование реестра, чтобы вернуть обработчик MS в положение по умолчанию.
Это была настоящая проблема: каждая проверка сертификата прошла сначала через Entrust DLL, которая выталкивала все в очередь, которая была опустошена только одним потоком/процессором. Затем он обнаружил, что не должен был иметь дело с этим сертификатом и передал его обработчику Microsoft.

Ответ 2

Во-первых, я предполагаю, что вы не делаете ничего глупого, как создание в сетевом местоположении или подключенном диске или перенаправляете папку "Документы"?

Следующий шаг - использовать диспетчер задач, чтобы увидеть, какие процессы замедляют работу. Используется ли процессор на 100%? Какие процессы активны? Много ли это подкачки (см. "Дефекты ошибок страницы" )? Какие процессы?

Я должен сказать, что это звучит как антивирус. Вы должны исключить OBJ, LIB, ILK, PDB и подобные типы файлов из антивирусного сканирования при доступе.

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

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

Ответ 3

Запустите MSBuild из командной строки с параметром verbosity, установленным в diag:

MSBuild mysolution.sln /v:diag

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

Ответ 4

Диагностический отчет покажет, как MSBuild работает на детальном уровне, но не всегда поможет диагностировать проблемы с производительностью. Попробуйте запустить обычную сборку, добавив следующие дополнительные параметры в командную строку msbuild:

/ds /clp:performancesummary

В результате вы получите краткое описание диагностики использования node, а также добавьте подробный сводку производительности в конец вывода консоли сборки, показывая, как долго выполняется каждая задача. Если вы используете файловый регистратор, вы можете добавить параметр "; performancesummary" в конец параметров вашего регистратора файлов (/flp:...).

Еще одна вещь, на которую следует обратить внимание, - уменьшить свойство AssemblySearchPaths, чтобы использовать только те пути, которые вы используете в своем проекте, это стало причиной проблем с производительностью в некоторых сборках, которые я видел. Просто выполните поиск в Microsoft.Common.targets, переопределите его в стандартном импорте, используемом всеми вашими проектами (у вас есть один из них, правый:) и переопределите его до того, где импортируются стандартные файлы, удалив любую из {...} элементы, которые вы не используете.