Время сборки CruiseControl на рабочей станции vmware снижается
У меня очень странная проблема, и моя последняя надежда на помощь, я подозреваю, исходит от этого сообщества.
У меня есть система сборки, которая включает в себя компиляцию трех различных элементов пакета мудрого установщика. Симптомы, которые я вижу, это то, что время сборки для этих проектов со временем специально снижается на виртуальных машинах. Это происходит на нескольких виртуальных машинах и происходит с ноября 2013 года. К счастью, у меня была привычка клонировать виртуальные машины, и у меня был клон машины в начале декабря, когда симптомы были на ранних стадиях.
Например, нормальное время сборки должно закончиться через 48-50 минут. Время ухудшалось медленно, и к тому времени, когда я заметил, что время проблем ухудшилось до 1 часа 45 минут. Я обычно не слежу за производительностью системы, а за результатами сборки - поэтому я никогда не знал. Клонированная машина, которую я имел, восстановит систему так, чтобы она собиралась в течение 1 часа 12 минут.
Анализируя время сборки, все время используется мудрым установщиком. Я попытался удалить и переустановить приложение. Я очистил временный каталог, запустил chkdsk и другие обычные операции отладки.
Один из мудрых проектов установщика - это модуль слияния, который требует перекомпиляции, поскольку он обновляет файл базы данных. Это должно занять всего 8 минут, чтобы скомпилировать. Это займет более 1/2 часа.
Кто-нибудь может подумать, что я мог бы найти для диагностики этой проблемы? Что может привести к деградации системы, чтобы в течение месяца мудрый установщик компиляции мог потерять до 45 минут времени сборки? ОС машины сборки: XPsp3 HDD: SSD Другие сборки выполняются на одном хосте и могут работать одновременно, но до ноября 2013 года это не влияло на производительность.
2 ответа
Проблема на самом деле с нашей визуальной студией.
Для каждой сборки мы увеличиваем номер версии двоичных файлов. У нас есть процесс, который выполняет и обновляет значение во всех файлах proj.
Когда Visual Studio компилируется, она добавляет информацию о сборке в реестр для каждого файла.net. Поскольку номер версии изменился, запись в реестре изменится. Реестр никогда не очищается. Итак, я только что накопил год или больше записей в реестре.
Когда запускается мудрый установщик, он сканирует реестр, я не уверен, почему сейчас. Используя ProcMon, мы видим, как работает процесс, и читаем рег. Так как реестр сильно раздулся, это замедляет время сборки.
Теперь большой вопрос будет, как предотвратить эту проблему на новой сборочной машине? Как очистить все записи CLSID для нашей сборки?
На нетронутой системе сборки Win7 вся сборка завершается менее чем за 20 минут!
Также я внес еще одно изменение в мудрые настройки студии для проекта. Вместо использования высокого сжатия я переключил его на сжатие mszip. Наш выходной файл на 50 МБ больше, но время сборки намного быстрее - даже на новой машине.
РЕШЕНИЕ:
Добавьте чистое решение задачи ДО изменения номера версии. Это одно изменение привело к очень последовательному времени сборки в течение нескольких месяцев.
Проблема заключалась в том, что компания изменила процесс изменения версии сборки и значений версии файла. Мало ли мы знали, что перестройка оставляла информацию о сборке в реестре при каждой сборке. Итак, список задач теперь выглядит так:
- Чистые.NET решения
- Увеличьте версию для версии файла и версии сборки.
- Сборка.NET-решений
Надеюсь, это поможет всем, кто сталкивается с той же проблемой.
Если мудрый установщик вызывает проблему, то вы можете попробовать запустить procmon, чтобы увидеть, что вызывает зависание. Регистратор производительности Windows - еще один полезный инструмент, который недавно объяснил Алоис Краус - http://geekswithblogs.net/akraus1/archive/2014/04/30/156156.aspx