3

我们有一个基于 Linux 的构建系统，其中一个构建包含许多不同的嵌入式目标（启用了相应的不同驱动程序和功能集），每个目标都使用另一个单一的主源代码树构建。

与其尝试将我们的基于 make 的系统转换为对多进程更友好的系统，我们只想找到同时为所有这些目标启动构建的最佳方法。我不确定如何获得最佳性能。

我考虑了以下可能的解决方案：

  • 许多单独的构建机器。缺点：共享代码的大量副本，或从（慢）共享驱动器工作。更多系统需要维护。
  • 较少数量的多处理器机器（可能是双四核），具有快速条带化 RAID 本地存储。缺点：我不确定它将如何扩展。似乎体积会成为瓶颈，但我不知道这些天 Linux 处理 SMP 的能力如何。
  • 类似的 SMP 机器，但带有运行 VMware 的管理程序或 Solaris 10。这是愚蠢的，还是会提供一些调度好处？缺点：没有解决存储瓶颈问题。

我打算坐下来尝试这些可能性，但我想检查一下我是否遗漏了什么。谢谢！

4

3 回答 3

1

As far as software solutions go, I can recommend Icecream. It is maintained by SUSE and builds on distcc.

We used it very successfully at my previous company, which had similar build requirements to what you describe.

于 2009-06-16T20:53:38.600 回答
0

If you're interested in fast incremental performance, then the cost of calculating the files which need to be rebuilt will dominate over the actual compile time and this will put higher demands on efficient I/O between the machines.

However, if you're mostly interested in fast full rebuilds (nightly builds, for example), then you may be better of rsyncing out the source tree to each build slave, or even have each build slave check out its own copy from source control. A CI-system such as Hudson would help to manage each of the slave build servers.

于 2009-06-12T20:56:13.600 回答
0

如果您的 makefile 足够完整且结构良好-j，如果您的构建机器有足够的内存，则该标志也可能有助于克服 I/O 瓶颈。这让 make 可以并行运行多个独立的任务，这样您的 CPU 在理想情况下将永远不会阻塞等待 I/O。通常，通过允许比机器中的 CPU 更多的任务，我发现了很好的结果。

从您的问题中不清楚您当前的 makefile 是否不适合此，或者您只是不想跳到与 make 完全不同的东西。

于 2009-06-17T04:35:11.963 回答