由于distcc不能保持状态,只能发送作业和标题,并让这些服务器只使用刚发送的数据并进行预处理和编译,我认为最新的distcc在可伸缩性方面存在问题.

在我的本地构建环境中有appx.要构建10,000个c / c文件,在使用20个构建服务器时,我只能比不使用distcc(但使用make -j)快2倍.

您认为这个问题是什么？

如果有人使用make -j和distcc实现了超过10 – 20次的可扩展性,请告诉我.

以下产品声称不可能使-j和distcc的缩放速度超过5倍.
http://www.electric-cloud.com/products/electricaccelerator.php

我认为这可以通过以下方式改进：

>让distccd服务器维护会话
>绑定到这些会话,他们将缓存自己的头目录
>预处理将从distccd服务器完成需求库
>这将通过LD_PRELOADed库libdistcc.so完成,该库将替换stat / open系统调用并通过网络获取头文件.
…

有人做过这种事吗？

我认为Electric Cloud也有类似的东西,但我认为我们有更多的优化空间：

>服务器应该通过非常快速的网络文件系统共享相同的源代码存储库.
>我们应该对构建文件进行解析并并行包含头部解析.
>在没有彻底改变构建描述的情况下,似乎非常强硬.
任何想法,现有技术,变通方法都是受欢迎的.

最佳答案 是的,distcc可以扩展到5倍以上.

我们必须弄清楚您的环境中的限制因素.

>一个常见问题是,您的makefile一次不会允许它实际分派多个文件.您可以查看正在运行的编译器进程数.如果这是问题,您可能需要调试makefile以允许更多的并行性.
>也许客户运行的许多工作由于某种原因无法分发. distcc客户端日志将告诉您是否是这种情况.
>也许由于某种原因,客户过载并且无法足够快地完成工作;但是,在达到这个目标之前你很可能会获得2个以上的工作.
>也许服务器超载,无法接受更多的工作.但是如果你有20台服务器,它们应该至少能够拥有一台服务器.
>也许网络已经饱和,客户端和服务器都在阻塞(不太可能在GbE上;可能在100Mb上).

考虑到黑客保持会议开放还为时过早,直到你知道限制因素是开始会话.

它可能是#1或#2.从您的日志中发布摘录.