由于我们在构建服务器上的构建越来越慢，我试图找出可能是什么原因。它似乎主要挂在.tlog文件的磁盘IO操作中，因为没有CPU负载并且构建仍然挂起。即使项目只包含10个cpp文件，它也会在CL.read.1.tlog文件中生成~5500行。
可疑的是，该文件反复包含相同的标题，尤其是提升标题占据了文件的90％。
这真的是预期的行为，这些文件是如此之大，有多余的内容，或者可能是从我们的源代码触发的问题？是否有可能导致此问题的循环包含或过多的标头包含？
更新1
在所有评论之后，我将尝试在此澄清一些更多细节。
- 我们只使用boost来包含头文件并链接已编译的库，我们不是在编译boost本身
- 是的，SSD总是一个很好的改进，但构建服务器由我们的IT托管，我们没有可用的SSD。 （见下文）
- 我在编译期间特别通过perfmon检查了一些perfcounters。虽然CPU和内存负载在大多数情况下可忽略不计，但磁盘IO计数器和队列大小始终相当高。磁盘活动 - 最高活动时间始终为100＆amp;如果我按总计（B /秒）对它进行排序，那么所有的tlog文件都会读取/写入大量数据到磁盘上。
- 即使5500行的tlog在某些情况下似乎没问题，我也想知道为什么反复包含完全相同的提升标题。 Here我检查自己标题的日志文件。
- 没有防病毒影响。因为我们知道它会影响我们的编辑，所以我停止了我的调查。
- 在我的本地开发人员机器上使用SSD需要大约16分钟来构建我们的整个解决方案，而在我们的构建服务器上使用“较慢”的磁盘需要大约2小时。 CPU和内存相当。 5500行文件只是20-30个项目解决方案中单个项目的一个例子。我们有一个项目，我们有大约30MB的tlog文件，其中有大约60,000行，只有这个项目需要一半的编译时间。
- 当然在编译期间机器上有一些基本的CPU负载。但它与其他具有SSD的开发人员机器无法比拟。
- 我们的.net解决方案包含45个项目，在12分钟内完成（包括使用WiX的安装项目）
对于使用SSD的开发者机器，我们至少从2小时减少到16分钟，具有可比较的CPU /内存配置，我对瓶颈的假设始终是硬盘。检查磁盘相关操作会导致我进入tlog文件，因为它们根据permon导致最高的磁盘活动。