BOND_MODE_ROUNDROBIN 0 （balance-rr模式）网卡的负载均衡模式
BOND_MODE_ACTIVEBACKUP 1 （active-backup模式）网卡的容错模式
BOND_MODE_XOR 2 （balance-xor模式）需要交换机支持
BOND_MODE_BROADCAST 3 （broadcast模式）
BOND_MODE_8023AD 4 （IEEE 802.3ad动态链路聚合模式）需要交换机支持
BOND_MODE_TLB 5 自适应传输负载均衡模式
BOND_MODE_ALB 6 网卡虚拟化方式

bonding模块的所有工作模式可以分为两类：多主型工作模式和主备型工作模式，balance-rr 和broadcast属于多主型工作模式而active-backup属于主备型工作模式。（balance-xor、自适应传输负载均衡模式（balance-tlb）和自适应负载均衡模式（balance-alb）也属于多主型工作模式，IEEE 802.3ad动态链路聚合模式（802.3ad）属于主备型工作模式

在内核文档中，列举了许多bonding驱动的参数，然后本文不是文档的翻译，因此不再翻译文档和介绍和主题无关的参数，仅对比较重要的参数进行介绍，并且这些介绍也不是翻译，而是一些建议或者心得。

ad_select： 802.3ad相关。如果不明白这个，那不要紧，抛开Linux的bonding驱动，直接去看802.3ad的规范就可以了。列举这个选项说明linux bonding驱动完全支持了动态端口聚合协议。

arp_interval和arp_ip_target： 以一个固定的间隔向某些固定的地址发送arp，以监控链路。有些配置下，需要使用arp来监控链路，因为这是一种三层的链路监控 ，使用网卡状态或者链路层pdu监控只能监控到双绞线两端的接口 的健康情况，而监控不到到下一条路由器或者目的主机之间的全部链路的健康状况。

primary： 表示优先权，顺序排列，当出现某种选择事件时，按照从前到后的顺序选择网口，比如802.3ad协议中的选择行为。

fail_over_mac： 对于热备模式是否使用同一个mac地址，如果不使用一个mac的话，就要完全依赖免费arp机制更新其它机器的arp缓存了。比如，两个有网卡，网卡1和网卡2处于热备模式，网卡1的mac是mac1，网卡2的mac是mac2，网卡1一直是master，但是网卡1突然down掉了，此时需要网卡2接替，然而网卡2的mac地址与之前的网卡1不同，别的主机回复数据包的时候还是使用网卡1的mac地址来回复的，由于mac1已经不在网络上了，这就会导致数据包将不会被任何网卡接收。因此网卡2接替了master的角色之后，最好有一个回调事件，处理这个事件的时候，进行一次免费的arp广播，广播自己更换了mac地址。

lacp_rate： 发送802.3ad的LACPDU，以便对端设备自动获取链路聚合的信息。

max_bonds： 初始时创建bond设备接口的数量，默认值是1。但是这个参数并不影响可以创建的最大的bond设备数量。

use_carrier： 使用MII的ioctl还是使用驱动获取保持的状态，如果是前者的话需要自己调用mii的接口进行硬件检测，而后者则是驱动自动进行硬件检测(使用watchdog或者定时器)，bonding驱动只是获取结果，然而这依赖网卡驱动必须支持状态检测，如果不支持的话，网卡的状态将一直是on。

mode： 这个参数最重要，配置以什么模式运行，这个参数在bond设备up状态下是不能更改的，必须先down设备(使用ifconfig bondX down)才可以配置，主要的有以下几个：
1.balance-rr or 0： 轮转方式的负载均衡模式，流量轮流在各个bondX的真实设备之间分发。注意，一定要用状态检测机制，否则如果一个设备down掉以后，由于没有状态检测，该设备将一直是up状态，仍然接受发送任务，这将会出现丢包。
2.active-backup or 1： 热备模式。在比较高的版本中，免费arp会在切换时自动发送，避免一些故障，比如fail_over_mac参数描述的故障。
3.balance-xor or 2： 我不知道既然bonding有了xmit_hash_policy这个参数，为何还要将之单独设置成一种模式，在这个模式中，流量也是分发的，和轮转负载不同的是，它使用源/目的mac地址为自变量通过xor|mod函数计算出到底将数据包分发到哪一个口。
4.broadcast or 3： 向所有的口广播数据，这个模式很XX，但是容错性很强大。
5.802.3ad or 4： 这个就不多说了，就是以802.3ad的方式运行。
…

xmit_hash_policy：
这个参数的重要性我认为仅次于mode参数，mode参数定义了分发模式 ，而这个参数定义了分发策略 ，文档上说这个参数用于mode2和mode4，我觉得还可以定义更为复杂的策略呢。
1.layer2： 使用二层帧头作为计算分发出口的参数，这导致通过同一个网关的数据流将完全从一个端口发送，为了更加细化分发策略，必须使用一些三层信息，然而却增加了计算开销，天啊，一切都要权衡！

2.layer2+3： 在1的基础上增加了三层的ip报头信息，计算量增加了，然而负载却更加均衡了，一个个主机到主机的数据流形成并且同一个流被分发到同一个端口，根据这个思想，如果要使负载更加均衡，我们在继续增加代价的前提下可以拿到4层的信息。

3.layer3+4： 这个还用多说吗？可以形成一个个端口到端口的流，负载更加均衡。然而且慢！ 事情还没有结束，虽然策略上我们不想将同一个tcp流的传输处理并行化以避免re-order或者re-transmit，因为tcp本身就是一个串行协议，比如Intel的8257X系列网卡芯片都在尽量减少将一个tcp流的包分发到不同的cpu，同样，端口聚合的环境下，同一个tcp流也应该使用本policy使用同一个端口发送，但是不要忘记，tcp要经过ip，而ip是可能要分段的，分了段的ip数据报中直到其被重组(到达对端或者到达一个使用nat的设备)都再也不能将之划为某个tcp流了。ip是一个完全无连接的协议，它只关心按照本地的mtu进行分段而不管别的，这就导致很多时候我们使用layer3+4策略不会得到完全满意的结果。可是事情又不是那么严重，因为ip只是依照本地的mtu进行分段，而tcp是端到端的，它可以使用诸如mss以及mtu发现之类的机制配合滑动窗口机制最大限度减少ip分段，因此layer3+4策略，很OK！

miimon和arp： 使用miimon仅能检测链路层的状态，也就是链路层的端到端连接(即交换机某个口和与之直连的本地网卡口)，然而交换机的上行口如果down掉了还是无法检测到，因此必然需要网络层的状态检测，最简单也是最直接的方式就是arp了，可以直接arp网关，如果定时器到期网关还没有回复arp reply，则认为链路不通了。

配置文件
/etc/modprobe.conf

alias bond0bonding
optionsbond0 mode=0 arp_interval=500arp_ip_target=172.16.64.86

也可以加载模块的时候直接指定mode
modprobe bonding -o bond0 mode=0
modprobe bonding -o bond1 mode=1

启动bond
ifenslave bond0 eth0 eth1

这种模式下bonding模块会将虚接口和所有的slave接口的MAC地址设置为一致。通过定时器，每个slave接口不断发送ARP包来不断更换交换机端口与MAC的对应关系。

这样使得每个网卡都在进行工作。这个ARP的发送规则是：

每arp_interval（MS）间隔向arp_ip_target发送arp请求。也可以向多个arp_ip_target发送arp请求。

观察交换机端口上所学习到的MAC地址，发现MAC会在两个端口上反复切换。

在BOND_MODE_ROUNDROBIN模式下，bonding对于发送和接收数据的处理逻辑是不一致的，对于数据的接收，bonding基本不做任何处理，纯粹依靠交换机端口与MAC的变化来实现交替接收数据。发送的话，交换机会根据数据的源MAC来学习端口和MAC之间的关系，所以bonding做到的就是选择不一样的网卡发送。

容错模式的配置方法和负载均衡模式基本差不多，只不过修改一下/etc/modprobe.conf即可。

alias bond0 bonding

options bond0 mode=1 miimon=100

bond_mii_monitor函数其本质的原理就是检测网卡的链路状态，bonding定义网卡有4个链路状态

BOND_LINK_UP： 正常状态（处于该状态的网卡是是潜在的发送数据包的候选者）

BOND_LINK_FAIL： 网卡出现故障，向状态BOND_LINK_DOWN 切换中

BOND_LINK_DOWN： 失效状态

BOND_LINK_BACK： 网卡恢复，向状态BOND_LINK_UP切换中

bond_mii_monitor函数就是依次检查网卡的链路状态是否处于这些状态，然后通过标记do_failover变量来说明当前是否需要切换slave网卡。

在BOND_MODE_ACTIVEBACKUP模式下，两块网卡其实有一块是不工作的，被设置为IFF_NOARP的状态。同时，bond虚设备，还有slave设备的MAC地址均一致，所以这张网卡不会被外界察觉存在。交换机也不存在想该端口发包的情况。当bond的mii检测发现当前的active设备失效了之后，会切换到这个备份设备上。

许多磁盘阵列设备采用了网卡虚拟化方式进行多网卡应用。
那balance-alb 来说，就是通过arp 协商决定的。bonding驱动截获本机发送的ARP应答，并把源硬件地址改写为bond中某个slave的唯一硬件地址，从而使得不同的对端使用不同的硬件地址进行通信。这样就实现了网络负载均衡。当其中的一个slave 失败，就会由其他的slave来接管，从而提高了网卡的容错能力。

能够实现这种处理方法的原因就是bonding修改了ARP应答的源地址导致，使得外界并不感知服务器存在多网卡的状态，在网络上确定了IP和MAC的唯一对应关系，保证了上层业务传输的逻辑一致性。同时内部的处理又交给不同的网卡，实现了负载均衡。

1. $KERNEL-ROOT/Documentation/networking/bonding.txt
   
2. http://blog.csdn.net/dog250/article/details/6376698
   

offload特性都是为了提升网络收/发性能。TSO、UFO和GSO是对应网络发送，在接收方向上对应的是LRO、GRO。
通过ethtool -k 可以从查看

$ sudo ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off

TSO(TCP Segmentation Offload)，是一种利用网卡对TCP数据包分片，减轻CPU负荷的一种技术，
有时也被叫做 LSO (Large segment offload) ，TSO是针对TCP的，UFO是针对UDP的。
如果硬件支持 TSO功能，同时也需要硬件支持的TCP校验计算和分散/聚集 (Scatter Gather) 功能。

GSO(Generic Segmentation Offload)，它比TSO更通用，基本思想就是尽可能的推迟数据分片直至发送到网卡驱动之前，
此时会检查网卡是否支持分片功能（如TSO、UFO）,如果支持直接发送到网卡，如果不支持就进行分片后再发往网卡。
这样大数据包只需走一次协议栈，而不是被分割成几个数据包分别走，这就提高了效率。

LRO(Large Receive Offload)，通过将接收到的多个TCP数据聚合成一个大的数据包，然后传递给网络协议栈处理，
以减少上层协议栈处理开销，提高系统接收TCP数据包的能力。

GRO(Generic Receive Offload)，基本思想跟LRO类似，克服了LRO的一些缺点，更通用。
后续的驱动都使用GRO的接口，而不是LRO。

RSS(Receive Side Scaling)，是一项网卡的新特性，俗称多队列。具备多个RSS队列的网卡，
可以将不同的网络流分成不同的队列，再分别将这些队列分配到多个CPU核心上进行处理，从而将负荷分散，充分利用多核处理器的能力。

在参加了一些以生产力和时间管理为主题的研讨会并阅读了一些关于这个话题的图书以后，我了解了一些深奥的概念并且对我曾经的工作方法产生了一些深刻的领悟。运用这个新的知识，我完全重新设计了我的工作流框架，而这极大地推动了我的生产力。
我想与你分享一些最重要的技巧，它们可以帮助你推动你的生产力，提升你的总产量，而且可能最重要的，使你空闲出时间从事其它的活动。
注意下面的技巧可以用在个人和专业两个方面，本质上这些原则是一样的。
所以，我们开始吧……

如果有一件事要排除在本文之外，那么就是这件事。重申一遍，永远不要把阅读邮件当做早上的第一件事。如果你这样做了，你会自动进入一种反应和被动的模式，而不是我们想要的、积极而富有创造性的模式

只在一天中预定的时间查看和回复邮件。这些时间应该在午饭之前，我们假设大概12:00-13:00，之后16:00左右再来一次。在这些时段，你的活力等级总会降低，所以你不会失去任何具有创造性的活力。不用担心，那些“紧急”E-mail，并不是那么紧急。

在企业环境中，会议是生产率的头号杀手。我这样说，你明白，我明白，每个人都明白（但也许不会承认）。
“会议是一种令人沉溺的、高度自我放纵的活动，企业和其他大规模组织习惯性的参与其中，仅仅因为他们真正的振奋自己。”——Dave Barry
确实，这是对其的概括。最有趣的是，会议同时扼杀了许多人的生产率。令人惊叹。所以，如果不是参加绝对重要的会议，就忽略它。比如说你手头有很多工作（这可能是真的）并且计划会后与同事见面来了解一些重要的事情。
如果开个会真的很重要（这是很罕见的事情），那么记住这些：
下午晚些时候再开会，那是你的生产率总是很低。
总要有一个关于讨论话题的议程，不要忽略这一点。
设定一个严格的结束时间，到时间就结束会议。
在得出一系列清晰的、可操作的步骤之前，不要离开会议室。

这很艰巨。信息时代的世界充满了干扰，它们来自各种可能的渠道，阻止你完成事务。我会将干扰分为两大类：我们自己产生的干扰和别人产生的干扰。
先来看我们自己产生的干扰。这想起来看似有些古怪，但事实是，我们成功的让自己不能保持高产，即使我们这样做是无意识的。有很多例子：把我们的E-mail和社交媒体账户，设置成当有“重要”的事情发生时就“通知”我们；像疯子一样在不同的事务之间切换；在Hacker News或者Reddit上设置一个快捷“关注”等等。
问题是，你应该以这样的方式配置你的工作环境——当你着手于一项工作时，没有什么能让你分心。首先，关闭你的手机、Facebook更新等等上面的消息提醒。下一步，关闭你的E-mail软件，如果你决定开着它，确保没有打开自动发送/收取选项。之后，消除任何可以访问那些不高产站点的渠道，包括你经常泡在上面的DZone、Hacker News等等。注意，我并没有说“不要用”。我说的是“消除访问渠道”。我们这里都是极客，所以我相信你们能够找到一个技术上的办法来搞定这件事。你可以使用一个低级的方法——编辑你机器上的Host文件来让facebook.com指向127.0.0.1，或者使用一个插件暂时限制对这些站点的访问。我个人使用 Blocksite plugin。通过这样的配置，你将能达到这样一种的状态——消除大多数你带给自己的干扰。
我们来看看由别人产生的干扰。你可能会争辩，说前文中的一些干扰是别人产生的；但是事实是，你自己产生的，因为没人强迫你浏览Twitter或者Facebook。在这里，我要说的是“强加于别人”的干扰。例如，多少次这样的案例发生在你身上？你收到一份你老板的E-mail，之后他打电话问你是否收到了他的邮件。这是在说生产率。或者这样的情况：你的同事在你调试代码的时候戳了戳你，并问你一些琐碎的东西怎么在Java中实现，而你想到的第一种回答是：“Google一下，混蛋！”
事实上，那些干扰躲避起来有点麻烦，因为很可能过分并逾越人们认可的界限。建议如下：使用耳机（尽管我发现有时这样也没用）；把来电放入语音信箱，之后再接听；在你的电脑上挂一张纸，写着“请勿打扰，编程中”等。你必须判断在你当下的工作中哪些是适合的，并依照执行。目的是能够形成一个不会被打扰的工作流程。

前一晚，你应该列一个明确的事务列表，它在第二天能够实现是很重要的。我说的不是有很多项目的大表，这永远不管用。而是精确的指出2-3个重要的任务，它们一旦完成，你的项目将有重要进展。比如像这样问：“如果我今天只完成了这两个任务，我会感到我的一天很高产吗？”如果是的，把它们记下来。

正如前文提到的，E-mail从不该是首先处理的。那么，应该是什么呢？列表中最重要的事务！你已经找到了一个最关键性的事务，那么你就坐下来搞定它，而不考虑任何其他的事情。理论上，你应该在“一坐”中完成它。休息片刻，之后处理你列表上第二重要的事务。我会在后面的部分谈谈如何为了优化结果而配置工作和休息。

我确信你们中的大多数很熟悉查询批处理。简单来说，你“批量处理”许多相似的DB查询，而只向数据库发送一个请求，这实现了更佳的性能。进行最好的优化。你猜怎么着，你可以在你的事务上使用类似的原则！通过这种方法，你能够将活动经费和从特定事务中产生的各种日常开销最小化。事务批处理的一个好例子，就是查看邮件（想到办法了吗？）、电话和几乎任何枯燥重复的工作。

另一个可以加到你的“生产率工具箱”中的东西，就是自动化的概念。作为程序员，我们就生活在一个相当自动化的环境中，但是我还是看到了许多“小插曲”——人们决定人工处理一些枯燥、平凡的事务，而这些事务可以轻易的被自动化处理。瞧，人类衰退了，比机器更不可靠了，当手头的事务无趣而又微不足道的时候就更加衰退了。让尽可能多的事务自动化处理。例如：实现一个只需单击一下的完整应用；只用一个脚本就能部署到生产服务器等等。说真的，不要为了那些机器能够处理的更快的事情，而损失精力和体力，没有你参与更可靠。
为了结果最大化，调整“工作”和“娱乐”
好，现在是时候说说怎样真正的配置一个工作框架了。我的建议是，分配特定的时间段给“工作”，并分配特定的时间段给“休息”，或者更好的“娱乐”。
例如，你会花费连续的45分钟，专注于处理特定的事务；之后紧跟着休息15分钟，在这段时间里你可以上网、查看你的社交媒体信息更新、阅读最新的Java Code Geeks文章等等。确保在休息期间把你的目光从屏幕上移开，并真正的做一些身体的轻微活动。说真的，“久坐会害死你”（sitting can kill you），站起来走一走。
概念上是这样的，撇开其他的东西，在自律并痛苦的经过了时间更长的“工作”时段之后，“娱乐”时段将扮演一个自我奖励的角色。我们的思维是难以理解的东西，但我可以向你保证，设定一个像这样的奖励机制，将帮助你在完成更多事情的同时，享受一些快乐时光。
有数不清的计时应用，来从技术的角度达成这一机制，并且你也可以用Pomodoro technique进行实验。

这里我想说的，是养成把所有东西记录下来的习惯。不管是你的一个新主意、一个你打算用来解决你手头的问题的新方法，或者是你明天要付的一个账单。你必须确保你的大脑容量不会被“记忆东西”消耗掉，而是专注于你正尝试达成的特定目标。
把你的大脑想象成一个电脑的CPU。你分配给他的“事情”，就像把许多进程加载到后台。这最终会导致挂起并无法正常工作。记录下东西的过程，会降低你大脑的负载，并让它表现的更理想。
列一些分开的列表，并把你的思想分类。这些列表可以包括“潜在项目”、“要买的东西”、“开发”等等。因此，过后你可以很快的浏览他们。

这是圣杯。这是我们想通过适当的设计我们的工作框架来尝试实现的。这是所有上述的提示想要让你实现的。我确信你已经经历过“流逝”的状态和“在区域中”的状态，因为它广为程序员所熟知。它就是，当你大脑完全专注，聚焦于特定的事务或者程序，而你基本上失去了对时间的感知的那个时间段。你写代码、写代码、写代码，其他什么都不存在。外部的刺激甚至不会在你的大脑中留下痕迹，只有你和你最喜欢的IDE。我敢打赌，在我们编程工作的所有进展中，80%出现在“流逝”的状态中。
Heck, 我在写这篇文章的时候，达到了“在区域中”的状态！
这里的底线是，你需要把自己摆在这样一个位置，你可以轻易地进入＂流逝＂的状态，并尽可能长时间的留在那里。这是我们的大脑进入工作状态的模式，并且这会使得你的生产率暴涨。我喜欢＂在区域中＂，并且我确信你也喜欢，那么为什么不给我们自己一个体验更多的机会呢？
因此，你会拥有它。关于你花费时间的一些建议。请在短时间段内进行尝试（比如一到两周），之后在讨论中告诉我进行得怎么样。你甚至可以发给我一封E-mail，我将会很高兴收到你的消息!
并且像以往一样，分享是关怀。如果你发现这些建议有帮助，和同事分享一下，让我们把我们的工作环境变更优越。

引用：http://www.linuxeden.com/html/news/20130608/140066.html

yum install mysql mysql-server
service mysqld start

作为经典的分布式编译工具，distcc 在日常工作中常为我们使用来解决大型项目在单一工作站上编译较慢的问题。
其主要用于对 C, Object C 以及 C++ 代码进行并行编译，将可以并行的编译任务分布于编译集群中的各个工作站，有效利用各机器资源，达到整体编译性能的成倍提升。
在类 Unix 系统上，distcc 使用 sendfile 系统调用在不同工作节点之间传送文件，尽管这种网络文件传输会占用一定的时间，他们对工作机的 CPU 资源占用却很小，
而且这种分发任务的方式能够简化构建环境的配置，distcc 在这方面同早期的一些基于共享文件系统的分布编译环境 (dmake, pvmmake 等等 ) 相比几乎是 0 配置。
distcc 对各个编译节点的本地系统库及头文件基本没有要求，即使在不同的节点上这些组件的版本不同也不会影响到最终编译结果的正确性，
实际情况是 distcc 会在本地 (client机) 完成存在版本依赖的编译任务。
这个在本地做过预处理的 ASCII 源文件及其他命令行选项即可唯一确定一个目标文件，而与此任务在哪台机器上运行无关，通过分发这种任务到各个节点，即可消除对头文件的依赖。
同理 distcc 通过在任务的分发节点做链接来消除对库文件的依赖。
然而，distcc 的缺点在于其负载均衡算法过于简单，distcc 的代理进程对各个工作机当前的负荷没有感知，分发预处理文件的唯一依据是主机出现在DISTCC_HOST环境变量中的次序，
主机名越靠前，就会得到更多的编译任务，然而当编译场中某些机器性能过差，整体编译性能会显著下降，当阻塞 Make 运行的编译任务运行在这些机器上的时候，这种性能变化尤为明显。

毫无疑问，在上述编译集群中，有必要采用负载均衡来使编译系能得到最大的优化。这就需要在编译集群中增加监控各工作机工作量的监控程序，动态检测和平衡编译机的负载。
一个有效的方案是使用 DMUCS（Distributed Multi-User Compilation System）应用。DMUCS 是一个实现于 distcc 之上的动态平衡和任务分布程序。它可以：

　　支持多用户同时编译，扩展性好，可以很好处理新增的负载。
　　支持多种操作系统所组成的编译集群。
　　可以使用具有多处理器（多核）编译主机的所有处理资源。
　　可以充分使用具有不同处理速度的编译主机，使整体编译性能达到最优。
　　可以保证参与编译的主机不会由于编译任务而产生超负载的情况。
　　考虑到了编译主机上由非编译任务所引起的负载情况。
　　支持从编译集群中动态的增加或者移除编译主机。

distcc 会安装如下可执行文件：

在/etc/init.d/distcc中添加
ps aux | sed ‘/grep/d’ | grep -q loadavg || loadavg -s A-desktop &
DEAMON_ARGS=”-j4 –pid-file……”

loadavg -s 是为了向主机A-desktop发送编译负载信息。
最后在DEAMON_ARGS参数中加入-jN,N表示当前机器上将运行几个编译进程。

配置dmucs
sudo vi /etc/default/dmucs
SERVER=yes
dmucs 是用于接收loadavg发送过来的编译负载信息，以及编译数据，用于在server端建立一个TCP的监听端口。
默认监听端口为9714，client端loadavg会与server端的dumucs建立TCP连接，发送和接收数据
可以用lsof | grep 9714 查看dmucs，当然先要启动dmucs。
最后再server上启动dmucs，和 distcc 守护进程
sudo /etc/init.d/dmucs start
sudo /etc/init.d/distcc start
在distcc中运行loadavg的意思是，server也参与编译工作。自己做自己的client。

client端设置，以B为例，C以此类推
设置/etc/default/distcc
sudo vi /etc/default/distcc
STARTDISTCC=”true”
ALLOWEDNETS=”127.0.0.1 192.168.0.1/16”
LISTENER=”192.168.0.2”
其他参数不变。
一般来说，LISTENER设置为本机Ip就可以了。

所以我们可以用如下命令代替，它可以自动搜索到本机ip，所以即使client重启ip变了，也不用担心
LISTENER=`ifconfig | grep ‘192.168’ | cut -d: -f2 | awk ‘{ print $1}’ | head -n1`

启动distcc 守护进程，client端不用启动dmucs，
sudo /etc/init.d/distcc start

最后在client端设置编译参数：
sudo vi ~/.bashrc
加入：
export ARCH=arm
export CROSS_COMPILE=”gethost –server A-desktop distcc arm-XXX-eabi-”
以同样的方式配置C完成以后就可以开始编译了，

选取一个linux kernel编译
make arm_defconfig
make -j20
console 会显示distcc的编译相关信息，
同时可以在当前编译的机器上，另外开一个console上输入distccmon-text来查看distcc分派编译包的信息

60-second instructions

1. For each machine, download distcc, unpack, and do
   ./configure && make && sudo make install
   
2. On each of the servers, run distccd –daemon, with –allow options to restrict access.
   
3. Put the names of the servers in your environment:
   export DISTCC_POTENTIAL_HOSTS=’localhost red green blue’
   
4. Build!
   cd ~/work/myproject; pump make -j8 CC=distcc
   

网上说：
联合使用distcc和ccache的效果就和仅使用 distcc一样。

http://distcc.samba.org/
http://dmucs.sourceforge.net/