CruiseControl的构建时间在vmware工作站上降低 [英] CruiseControl Build times degrade on vmware workstation

问题描述

我遇到了一个非常奇怪的问题，我怀疑我最近寻求帮助的希望来自这个社区.

I have a very strange problem and my last hope for help I suspect comes from this community.

我有一个构建系统，其中包含编译一个明智的安装程序包的三个不同元素.我看到的症状是这些项目的构建时间会随着时间在虚拟机上特别降低.自2013年11月以来，这种情况一直在多个虚拟机上发生.幸运的是，我有克隆虚拟机的习惯，并在12月初克隆了该虚拟机，当时症状就在早期.

I have a build system that incorporates compiling three different elements of a wise installer package. The symptoms that I am seeing is that build times for these projects specifically degrade over time on the virtual machines. This is occurring on multiple virtual machines and has been doing so since November of 2013. Fortunately I had a habit of cloning the virtual machines and had a clone of the machine in early December where the symptoms were in the early stages.

例如，正常的构建时间应在48到50分钟内完成.时间慢慢变慢，到我注意到问题的时间降为1小时45分钟.我通常不是在监视系统的性能，而是在监视构建的结果-因此我从来都不知道.我拥有的克隆机器将还原系统，以便它在大约1小时12分钟时生成.

For instance a normal build time should finish in 48 to 50 minutes. Times degraded slowly that by the time I noticed the problems times had degraded to 1hr 45min. I am not normally monitoring performance of the system but the results of the build - so I never knew. The cloned machine I had will restore the system so that it builds at 1hr 12 min approx.

分析构建时间，明智的安装程序会一直使用这些时间.我试图卸载并重新安装该应用程序.我已经清理了temp目录，运行chkdsk和其他常规调试操作.

Analyzing the build times, all of the time is being used by the wise installer. I have attempted uninstall and reinstalling the application. I have cleaned the temp directory, run chkdsk, and other normal debugging operations.

明智的安装程序项目之一是合并模块，由于它更新了数据库文件，因此需要重新编译.只需花费8分钟即可进行编译.这需要1/2个小时以上.

One of the wise installer projects is a merge module that requires recompile because it updates a database file. This should only take 8 minutes to compile. It takes over 1/2 hour.

有人能想到我要寻找的诊断该问题的东西吗?是什么会导致系统性能下降，以至于明智的安装程序在一个月的编译过程中可能会减少多达45分钟的构建时间? 生成计算机操作系统:XPsp3 硬盘:SSD 其他构建确实可以在同一主机上运行，​​并且可以同时运行，但是在2013年11月之前，这不会影响性能.

Can anyone think of what I could look for to diagnose this problem? What could degrade the system so that in the course of a month the wise installer compile can loose up to 45 minutes on its build time? Build Machine OS: XPsp3 HDD: SSD Other builds do run on the same host machine and can run concurrently but previous to November 2013 this did not have an impact on performance.

推荐答案

问题实际上出在我们的Visual Studio版本上.

The problem is actually with our visual studio build.

对于每个构建，我们都增加二进制文件的版本号.我们有一个过程可以执行和更新所有proj文件中的值.

For each build we increment the version number of binaries. We have a process that executes and updates the value in all proj files.

Visual Studio编译时，会为每个.net文件将程序集信息添加到注册表中.由于版本号已更改，因此注册表项也会更改.注册表永远不会清理.因此，我刚刚积累了一年或更长时间的注册表项.

When visual studio compiles it adds assembly information to the registry for every .net file. Since the version number changed, the registry entry changes. The registry is never cleaned up. So I have just accumulated a year or more of registry entries.

当明智的安装程序运行时，它正在扫描注册表，我不确定为什么现在.使用ProcMon，我们可以看到进程正在运行并读取reg.由于注册表过分膨胀，因此减慢了构建时间.

When wise installer runs it is scanning through the registry, I am not certain why right now. Using ProcMon we can see the process running and reading the reg. Since the registry has bloated so much it slows down the build time.

现在最大的问题是如何在新的构建机器上防止该问题?如何为我们的构建清理所有CLSID条目?

Now the big question will be how to prevent this problem on a new build machine? How do I clean up all CLSID entries for our build?

在原始Win7构建系统上，整个构建将在20分钟内完成！

On a pristine Win7 build system the entire build completes in under 20 min!

此外，我对项目的明智工作室设置进行了另一处更改.我没有使用高压缩率，而是将其切换为mszip压缩.我们的输出文件大了50MB，但是构建时间要快得多-即使在新机器上.

Also, I made one more change to the wise studio settings for the project. Instead of using high compression I switched it to mszip compression. Our output file is 50MB larger but the build time is far quicker - even on a new machine.

解决方案:

在更改版本号之前添加干净的解决方案任务.这一更改导致几个月的构建时间非常一致.

Add a clean solution task BEFORE changing the version number. This one change has resulted in a very consistent build time over several months.

问题在于该公司已更改了更改程序集版本和文件版本值的过程.我们几乎不知道重建会在每次构建时都将程序集信息保留在注册表中.所以任务列表现在看起来像:

The problem was that the company had changed the process of changing the assembly version and file version values. Little did we know that a rebuild was leaving assembly information in the registry on every build. So the task list now looks like:

• 干净的.NET解决方案
• 增加文件版本和程序集版本的版本.
• 构建.NET解决方案

希望这对遇到相同问题的其他人有所帮助.

Hopefully this helps anyone else who encounters the same problem.

这篇关于CruiseControl的构建时间在vmware工作站上降低的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！