使用distcc分布式编译的特点与潜在问题.doc

使用 distcc 分布式编译的特点与潜在问题 作为经典的分布式编译工具，distcc 在日常工作中常为我们使用来解决大型项目在单一工作站上编译较慢的问题。其主要用于对 C, Object C 以及 C++ 代码进行并行编译，将可以并行的编译任务分布于编译集群中的各个工作站，有效利用各机器资源，达到整体编译性能的成倍提升。 在类 Unix 系统上，distcc 使用 sendfile 系统调用在不同工作节点之间传送文件，尽管这种网络文件传输会占用一定的时间，他们对工作机的 CPU 资源占用却很小，而且这种分发任务的方式能够简化构建环境的配置，distcc 在这方面同早期的一些基于共享文件系统的分布编译环境 (dmake, pvmmake 等等 ) 相比几乎是 0 配置。 distcc 对各个编译节点的本地系统库及头文件基本没有要求，即使在不同的节点上这些组件的版本不同也不会影响到最终编译结果的正确性，实际情况是 distcc 会在本地 (client 机 ) 完成存在版本依赖的编译任务，这一点的实现原理简要说来式因为 distcc 借助了 C/C++ 编译驱动程序的以下特点： cpp(C 预处理器 ) [cpp [arguments] .c 源文件输入 .i 中间文件输出 ] ccl(C 编译器 ) [ccl .i 中间文件输入 .c 源文件输入 [arguments] –o .s 汇编文件输出 ] as( 汇编器 ) [as [arguments] –o .o 目标文件输出 .s 汇编文件输入 ] 这个在本地做过预处理的 ASCII 源文件及其他命令行选项即可唯一确定一个目标文件，而与此任务在哪台机器上运行无关，通过分发这种任务到各个节点，即可消除对头文件的依赖。同理 distcc 通过在任务的分发节点做链接来消除对库文件的依赖。 然而，distcc 的缺点在于其负载均衡算法过于简单，distcc 的代理进程对各个工作机当前的负荷没有感知，分发预处理文件的唯一依据是主机出现在 DISTCC_HOST 环境变量中的次序，主机名越靠前，就会得到更多的编译任务，然而当编译场中某些机器性能过差，整体编译性能会显著下降，当阻塞 Make 运行的编译任务运行在这些机器上的时候，这种性能变化尤为明显。 假设这样一种极端的情况：集群中两台工作机中一台使用 4 个强劲的 CPU，而另一台性能较弱的机器只有 2 个较弱的 CPU。如果使用 distcc 启动并行数量为 6 的编译任务，这将导致较弱的 2 CPU 工作机负载过载而较强的 4CPU 工作机负载过轻，这样的非均匀负载分布将拖累整个编译任务。如图所示： 图 1：无负载均衡的并行编译任务演示  回页首 一种实现负载均衡的解决方案：使用 DMUCS 毫无疑问，在上述编译集群中，有必要采用负载均衡来使编译系能得到最大的优化。这就需要在编译集群中增加监控各工作机工作量的监控程序，动态检测和平衡编译机的负载。 一个有效的方案是使用 DMUCS（Distributed Multi-User Compilation System）应用。DMUCS 是一个实现于 distcc 之上的动态平衡和任务分布程序。它可以： 支持多用户同时编译，扩展性好，可以很好处理新增的负载。 支持多种操作系统所组成的编译集群。 可以使用具有多处理器（多核）编译主机的所有处理资源。 可以充分使用具有不同处理速度的编译主机，使整体编译性能达到最优。 可以保证参与编译的主机不会由于编译任务而产生超负载的情况。 考虑到了编译主机上由非编译任务所引起的负载情况。 支持从编译集群中动态的增加或者移除编译主机。 DMUCS 以下四个部分程序组成。 dmucs 主服务程序。 DMUCS 解决方案的核心服务程序。每个编译集群仅运行一个 dmucs 主服务程序，其运行于哪一台主机上没有限制。该程序从一个配置文件读出编译场里处理器数目和每个可能主机的“潜能”。然后从网络接收每个编译主机的平均负载信息，编译任务数量和监控程序得到的编译请求信息。dmucs 管理一个编译场里主机的数据库，并调度主机去编译任务，当有编译请求时给出可用的最快的主机 / 处理器。 Loadavg 监控程序 编译场的每个参与编译的主机上均需要启动这个程序。loadavg 定期发送编译主机的平均负载到 dmucs 服务器。这样当某个主机的平均负载太高时，dmucs 服务器会将不会优先给该主机分配编译任务。 gethost 编译命令 gethost 是具体进行编译的命令，其运行于 distcc 之上。该命令从运行 dmucs 主服务程序的主机获取编译集群中的机器信息来获得放进 DISTCC_HOSTS 环境变量里的主机，然后调用所分配的编译机进行