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

Question

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

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

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

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

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

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

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

Answer 1

Во-первых, я предполагаю, что вы не делаете ничего глупого, например, строите сетевое местоположение или подключенный диск, или перенаправляете папку «Documents»?

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

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

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

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

Answer 2

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

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

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

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

РЕДАКТИРОВАТЬ: Проблема решена с версией 10 Entrust Entelligence.Он больше не устанавливается по умолчанию в качестве первого обработчика сертификатов в системе.
На v9 требуется ручное редактирование реестра, чтобы вернуть обработчик MS в положение по умолчанию.
Это была настоящая проблема: каждый сертификатпроверка прошла сначала через Entrust DLL, которая помещала все в очередь, которая была очищена только одним потоком / процессором.Затем он обнаружил, что не должен иметь дело с этим сертификатом, и передал его обработчику Microsoft.

Answer 3

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

MSBuild mysolution.sln /v:diag

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

Answer 4

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

/ds /clp:performancesummary

Это выведет диагностическую сводку об использовании узла, а также добавит подробную сводку производительности в конец вывода консоли:сборка, показывающая, как долго выполняется каждая задача.Если вы используете файловый регистратор, вы можете добавить опцию «; performancemancesummary» в конец параметров вашего файлового регистратора (/flp:...).

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