DongHao: 11 2009存档
昨天看探索，讲美国M1主战坦克的生产，说GE（美国通用电力）公司已经很久没有生产新M1坦克了，都是用旧的生锈了的老M1钢架进行翻新升级，造出来的
一样是先进好用的新坦克。真想不到连军火生产都实现循环回收了，不得不佩服GE的精细化运作，连坦克生产都有“绿色环保”的理念在里面。
突然想起互联网公司用的大量服务器，不知道这些服务器如果被淘汰下线以后，是否还会回炉？另外，大量的台式机、笔记本更新换代以后，都到哪里去了？听到这 方面的信息特别少，估计就是和普通垃圾一样直接填埋了事——当然，也能使作为电子垃圾出口落后国家（比如国内的低端黑莓）。IT行业整天吹“长尾”、“节 约”、“环保”，在节能绿色方面如果真的和GE这类工业老手比，还不知道胜败如何呢。
突然想起互联网公司用的大量服务器，不知道这些服务器如果被淘汰下线以后，是否还会回炉？另外，大量的台式机、笔记本更新换代以后，都到哪里去了？听到这 方面的信息特别少，估计就是和普通垃圾一样直接填埋了事——当然，也能使作为电子垃圾出口落后国家（比如国内的低端黑莓）。IT行业整天吹“长尾”、“节 约”、“环保”，在节能绿色方面如果真的和GE这类工业老手比，还不知道胜败如何呢。
豆瓣果然是个好地方，多奇怪多搞笑的书都有，而且大家还给了相当高的评价，如：
《身体腾空特异功能修持密法》
作者是大名鼎鼎的奥姆真理教的头子，但国内居然出版了，以后见到“北京体育学院出版社”要小心了，说不定有会武术、能腾空而起、谁也拦不住的高手（简称“武腾拦”）。
《怎样养猪赚钱多》
《怎样养猪多赚钱》
总之是要赚钱
《怎样打飞机》
广州军区司令部内部资料，不许外传
《葫芦娃大战变形金刚》
这才是中西合璧、土洋结合的典范，谁说中国的编剧不如美国？美国编剧能让这两伙人撞上吗？本书得分9.0，一定非常精彩！
《身体腾空特异功能修持密法》
作者是大名鼎鼎的奥姆真理教的头子，但国内居然出版了，以后见到“北京体育学院出版社”要小心了，说不定有会武术、能腾空而起、谁也拦不住的高手（简称“武腾拦”）。
《怎样养猪赚钱多》
《怎样养猪多赚钱》
总之是要赚钱
《怎样打飞机》
广州军区司令部内部资料，不许外传
《葫芦娃大战变形金刚》
这才是中西合璧、土洋结合的典范，谁说中国的编剧不如美国？美国编剧能让这两伙人撞上吗？本书得分9.0，一定非常精彩！
本来是想查Intel的“sfence”指令，却找到了这篇文章：http://www.cnblogs.com/flier/archive/2004
/07/08/22352.html
乍一看吓一跳，内存拷贝可以提高50%的性能！，那我们以前用的的memcpy岂不是很菜？！于是按照文章的代码试着在linux上写了个
fast_memcpy函数，测试了一下。好久没写gcc里的嵌入汇编，折腾了半天。
结果发现不如memcpy快。如果我把mm0换成别的寄存器，比如rax、r8等，则movntq根本不可用，zhe这下明白了，movntq加sfence是针对MMX寄存器用的，对普通的内存拷贝没有帮助。
结果发现不如memcpy快。如果我把mm0换成别的寄存器，比如rax、r8等，则movntq根本不可用，zhe这下明白了，movntq加sfence是针对MMX寄存器用的，对普通的内存拷贝没有帮助。
hugepage采用了大页面（2MB或4MB一个page），理论上页表的索引更小，访问就更快。介绍的资料如下：
http://www.kernel.org/doc/ols/2006/ols2006v2-pages-83-90.pdf 里面还介绍了怎样使用hugepages，但我按它的方法却不好使，最后是把hugetlbfs mount到某个目录，然后在里面创建一个文件，mmap之，注意，hugetblfs里的文件只能通过mmap操作
使用方法可参考：
http://www.cyberciti.biz/tips/linux-hugetlbfs-and-mysql-performance.html
我简单测了一下，分配2G的空间，顺序写一遍，hugepage（2MB一个页面）比malloc快3%
如果把2G空间分成2048份，每份写5遍，（这时模拟实际使用，访问的空间局部性），hugepage比malloc快6%，这和上面那篇论文提到的性能提升是一致的。
感觉在随机读写的时候hugepage表现更好,我猜测是因为CPU的 L1 cache 把页索引缓存，所以非常快。
http://www.kernel.org/doc/ols/2006/ols2006v2-pages-83-90.pdf 里面还介绍了怎样使用hugepages，但我按它的方法却不好使，最后是把hugetlbfs mount到某个目录，然后在里面创建一个文件，mmap之，注意，hugetblfs里的文件只能通过mmap操作
使用方法可参考：
http://www.cyberciti.biz/tips/linux-hugetlbfs-and-mysql-performance.html
我简单测了一下，分配2G的空间，顺序写一遍，hugepage（2MB一个页面）比malloc快3%
如果把2G空间分成2048份，每份写5遍，（这时模拟实际使用，访问的空间局部性），hugepage比malloc快6%，这和上面那篇论文提到的性能提升是一致的。
感觉在随机读写的时候hugepage表现更好,我猜测是因为CPU的 L1 cache 把页索引缓存，所以非常快。
从这篇测试文章可以看出，hugepages不仅速度更快，而且更省内存（页表项少了很多！），所以他的结论是：如果在linux上跑数据库，最好用hugepages。
今年的linux内核开发大会上，google的开发人员也上台做了名为“how google use linux"的演讲。我斗胆翻译注解一番——括号内为注解，欢迎读者斧正。
（前面几段讲google对linux kernel代码的管理及跟进，偏细碎，不翻译了）
在google为linux加入的代码中，3/4是对内核核心的改动，设备驱动代码只是其中相对较小的一部分。
（linux发展到现在这个阶段，需要加入的新的设备驱动已经越来越少了）
如果google要与linux社区的合作开发，那将面临一系列问题。跟上linux代码的主干太难——它的代码更新的太快了。在一个大型项目 里，开发者对补丁的提交、重改确实是个问题。Alan Cox对此的回答十分简单：人总是贪得无厌的，但有时候就应该简单的对他们说”不“。
（Alan Cox是linux kernel的二号功臣，现已加入Intel公司。我觉得Intel这样的CPU公司很适合内核开发者）
在CPU调度上，google发现想改用新的cfs（“完全公平调度”，由Con Kolivasy在2.6.23中加入内核）非常麻烦。由于太麻烦，google不得不倒回去把O(1) sheduler（2.6.23前内核使用的调度算法，想知道这段具体的历史，可以参考另一篇cfs文章）移植到2.6.26上，一切才能运转起来。内核对sched_yield()语义的更改也造成了麻 烦，尤其当google使用用户态锁时。高优先级的线程会对服务器的负载均衡（这里的负载均衡指的是一台服务器上多个CPU对多任务的分配处理，不是指分布式）造成影响，哪怕这些线程只是运行很短的时间。而负载均衡很重要：google通常在16-32核的服务器上跑5000个线程（好诡谲的用法！）。
在内存管理上，新的linux内核改变了对脏数据的管理，导致出现了大量主动的写回操作（脏数据要写回硬盘）。系统很容易出现这种局 面：kswaped（swap进程）会产生大量小的I/O操作，塞满块设备的请求队列，结果造成别的写回无法完成（写回“饥饿”）；这个问题已经通过 “per-DBI写回机制”补丁在2.6.32内核中解决了。
（per-DBI的主要原理是块设备不再只有一个等待队列，而是多个，每个“硬盘轴”一个队列，因为硬盘轴是一个硬件上的真正的工作单位。这样，对装配多个硬盘的服务器会有很好的I/O性能。不过我个人猜测，如果能把kswaped的小请求合并，是否也能提高性能呢？）
如上所述，google在系统中启动很多线程——不寻常的用法。他们发现如果向一个大的线程组发信号，会造成运行队列锁的大量竞争。google 还发现mmap_sem信号量（是内核结构 struct mm_struct中用来保护mmap空间的内核信号量）有竞争问题；一个睡眠的读者会阻塞写者，而这个写者又阻塞了其他读者，最后造成系统死锁。内核应该修改，拿到信号量以后不要 再等待I/O。
（google所说的信号对线程组造成的问题估计是“惊群效应”，就是很多任务睡在一个队列上，一个唤醒操作会造成他们都突然醒来，结果必然是资源拥挤。我个人认为这不是linux的问题，这是google使用linux的方法太奇特了，所以内核开发者没有注意到）
google大量使用了OOM killer来减轻高负载服务器的负担。这样做有一定的麻烦，当拥有锁的进程被OOM杀掉时（锁并不会释放，结果就阻塞了别的任务）。Mike（演讲人） 很想知道为什么kernel费那么大劲搞出OOM killer来，而不是简单的在分配内存失败后返回一个错误。
（不光Mike，大家都有这样的 疑问，估计答案只能在内核邮件组里找了。而google所说的那个“进程被杀锁却没释放、造成阻塞”的问题，yahoo在freebsd-4.11的时代 就已经解决了，用了很巧很轻量级的办法。大家都觉得google的技术最牛，其实公正的说，牛公司牛人很多，只是大家没他那么高调而已。但对国内来说，能 通过改进内核来提高服务器的公司，也真是凤毛麟角了。）
（此外略去一段google对内核开发工作的分类，看不太懂）
google增加了一种SCHED_GIDLE的调度类，是真正的空闲类;如果没有CPU供使用，属于此类的任务就彻底不运行（甚至不参与对 CPU的抢夺）。为了避免“优先级反转”问题，SCHED_GIDLE类的进程在睡眠时（此处指内核睡眠，不是系统调用sleep造成的睡眠）会临时提高 优先级。网络由HTB排队规则管理，配有一组流量控制逻辑。对硬盘来说，它们按linux的I/O调度来工作。
（假设三个进程A、B、C，优先级 为A>B>C，假设C先运行，占了一个重要的共享资源，A也想要这个资源，所以A等待C完成，但由于B的优先级比C高，结果C还没完成就调度 到B运行了，这样总的来看，B的运行先于A，尽管A的优先级比B高。这就是“优先级反转”问题。通常的解决方法是：谁占了重要的共享资源，谁就临时提升自 己的优先级，比如C占了资源后优先级临时升到和A一样高，释放资源后再把优先级降回来。说白了，占用资源的一伙人，他们最好有相同的优先级，不然会有麻 烦）
除了这些，google还有很多代码用于监控。监控所有的硬盘和网络流量，记录之，用于后期对运维的分析。google在内核加了很多钩子，这样 他们就能把所有的硬盘I/O情况返回给应用程序——包括异步的写回I/O。当Mike被问到他们是否使用跟踪点时，回答是“是的”，但是，自然 的，google使用的是自己的一套跟踪方法。
google内核改进在2010年还有很多重要的目标：
google对CPU限制功能很兴奋，通过此功能，就能给“低延时任务”较高的优先级，而不必担心这些任务把霸占整个系统。
基于RPC的CPU任务调度，这包括监控RPC入口流量，以决定唤醒哪一个进程。（这很有分布式OS的味道）
延迟调度。对很多任务来说，延迟并不是什么大不了的事。但当RPC消息到来时，内核却尝试去运行所有这些任务；这些消息不会分布到不同的CPU上（意思就是处理这些请求的服务进程可能就在某几个CPU上运转），这造成了系统负载在CPU间分配的问题。所以任务应该能被标为“延迟调度”；当被唤醒后，这些任务并不会被直接放到运行队列上，而是等待，知道全局的CPU负载调度完成。
插入空闲周期。高级电源管理使google能够把服务器用到接近烧毁的边缘——但是不超过这个边缘。
更好的内存管理已经列入计划，包括统计内核的内存使用。
“离线内存”。Mike强调想买到便宜好用的内存是越来越难。所以google需要能够把坏内存标出的功能。HWPOISON兴许可以帮到他们。
在网络方面，google希望改进对“接收端缩放”的支持——即把输入流量导到指定的队列。google还需要统计软件中断次数然后转给指定的任务——网络进程通常包含大量的软中断。google已经在拥塞控制上做了很多工作；他们开发了“网络不安全”的拥塞算法，该算法在google的数据中心运转良好。名为“TCP pacing”的算法放慢了服务器的输出流量，避免了交换机过载。
（自己管理数据中心的公司就是不一样，网络优化做得很细）
在存储方面，google花了大量精力降低块设备层的瓶颈，这样就能更好的使用高速flash。在块设备层通过flash来提高存储效率已经列入了开发计划。google考虑在内核里增加flash转换层，但大家建议google还是把操作flash的逻辑直接放入文件系统层更好一些。
Mike最后总结了几个“感兴趣的问题”。其中一个是google希望把文件系统的元数据固定在内存里。目的是减少I/O请求的时间。从硬盘读取一个块的时间是已知的，但是如果元数据不在内存中，就会有不只一个I/O操作被执行（会有新的I/O操作用来读元数据）。这样就减慢了读文件的速度。google目前对此问题的解决方案是直接从原始块设备读取数据到用户空间（估计是用O_DIRECT，然后自己在用户态管理元数据缓存，这样就不会使用系统的cache），但以后不想 再这么做了。
（不知道google所说的filesystem metadata到底指哪些数据，因为不同的文件系统，metadata也很不同，既然google说要把这些数据固定在内存里，估计应该不大，那自己缓存有什么不好？希望有机会可以问问Mike）
还有一个问题，使用fadvise会降低系统调用的性能。目前还不清楚问题的细节。
google的这个演讲很成功，linux社区也从自己最大的客户那里学到了不少东西。如果google更加面向linux社区的计划能够付诸行动，那linux将会拥有一个更好的kernel。
（注：google可算是IT公司中使用linux最多的，也很可能是使用得最深的，30个人的内核开发队伍，非常可观。看看国内，很少公司、很少人为开源做过贡献，唉，说起来惭愧，在下也是之一啊。）
（前面几段讲google对linux kernel代码的管理及跟进，偏细碎，不翻译了）
在google为linux加入的代码中，3/4是对内核核心的改动，设备驱动代码只是其中相对较小的一部分。
（linux发展到现在这个阶段，需要加入的新的设备驱动已经越来越少了）
如果google要与linux社区的合作开发，那将面临一系列问题。跟上linux代码的主干太难——它的代码更新的太快了。在一个大型项目 里，开发者对补丁的提交、重改确实是个问题。Alan Cox对此的回答十分简单：人总是贪得无厌的，但有时候就应该简单的对他们说”不“。
（Alan Cox是linux kernel的二号功臣，现已加入Intel公司。我觉得Intel这样的CPU公司很适合内核开发者）
在CPU调度上，google发现想改用新的cfs（“完全公平调度”，由Con Kolivasy在2.6.23中加入内核）非常麻烦。由于太麻烦，google不得不倒回去把O(1) sheduler（2.6.23前内核使用的调度算法，想知道这段具体的历史，可以参考另一篇cfs文章）移植到2.6.26上，一切才能运转起来。内核对sched_yield()语义的更改也造成了麻 烦，尤其当google使用用户态锁时。高优先级的线程会对服务器的负载均衡（这里的负载均衡指的是一台服务器上多个CPU对多任务的分配处理，不是指分布式）造成影响，哪怕这些线程只是运行很短的时间。而负载均衡很重要：google通常在16-32核的服务器上跑5000个线程（好诡谲的用法！）。
在内存管理上，新的linux内核改变了对脏数据的管理，导致出现了大量主动的写回操作（脏数据要写回硬盘）。系统很容易出现这种局 面：kswaped（swap进程）会产生大量小的I/O操作，塞满块设备的请求队列，结果造成别的写回无法完成（写回“饥饿”）；这个问题已经通过 “per-DBI写回机制”补丁在2.6.32内核中解决了。
（per-DBI的主要原理是块设备不再只有一个等待队列，而是多个，每个“硬盘轴”一个队列，因为硬盘轴是一个硬件上的真正的工作单位。这样，对装配多个硬盘的服务器会有很好的I/O性能。不过我个人猜测，如果能把kswaped的小请求合并，是否也能提高性能呢？）
如上所述，google在系统中启动很多线程——不寻常的用法。他们发现如果向一个大的线程组发信号，会造成运行队列锁的大量竞争。google 还发现mmap_sem信号量（是内核结构 struct mm_struct中用来保护mmap空间的内核信号量）有竞争问题；一个睡眠的读者会阻塞写者，而这个写者又阻塞了其他读者，最后造成系统死锁。内核应该修改，拿到信号量以后不要 再等待I/O。
（google所说的信号对线程组造成的问题估计是“惊群效应”，就是很多任务睡在一个队列上，一个唤醒操作会造成他们都突然醒来，结果必然是资源拥挤。我个人认为这不是linux的问题，这是google使用linux的方法太奇特了，所以内核开发者没有注意到）
google大量使用了OOM killer来减轻高负载服务器的负担。这样做有一定的麻烦，当拥有锁的进程被OOM杀掉时（锁并不会释放，结果就阻塞了别的任务）。Mike（演讲人） 很想知道为什么kernel费那么大劲搞出OOM killer来，而不是简单的在分配内存失败后返回一个错误。
（不光Mike，大家都有这样的 疑问，估计答案只能在内核邮件组里找了。而google所说的那个“进程被杀锁却没释放、造成阻塞”的问题，yahoo在freebsd-4.11的时代 就已经解决了，用了很巧很轻量级的办法。大家都觉得google的技术最牛，其实公正的说，牛公司牛人很多，只是大家没他那么高调而已。但对国内来说，能 通过改进内核来提高服务器的公司，也真是凤毛麟角了。）
（此外略去一段google对内核开发工作的分类，看不太懂）
google增加了一种SCHED_GIDLE的调度类，是真正的空闲类;如果没有CPU供使用，属于此类的任务就彻底不运行（甚至不参与对 CPU的抢夺）。为了避免“优先级反转”问题，SCHED_GIDLE类的进程在睡眠时（此处指内核睡眠，不是系统调用sleep造成的睡眠）会临时提高 优先级。网络由HTB排队规则管理，配有一组流量控制逻辑。对硬盘来说，它们按linux的I/O调度来工作。
（假设三个进程A、B、C，优先级 为A>B>C，假设C先运行，占了一个重要的共享资源，A也想要这个资源，所以A等待C完成，但由于B的优先级比C高，结果C还没完成就调度 到B运行了，这样总的来看，B的运行先于A，尽管A的优先级比B高。这就是“优先级反转”问题。通常的解决方法是：谁占了重要的共享资源，谁就临时提升自 己的优先级，比如C占了资源后优先级临时升到和A一样高，释放资源后再把优先级降回来。说白了，占用资源的一伙人，他们最好有相同的优先级，不然会有麻 烦）
除了这些，google还有很多代码用于监控。监控所有的硬盘和网络流量，记录之，用于后期对运维的分析。google在内核加了很多钩子，这样 他们就能把所有的硬盘I/O情况返回给应用程序——包括异步的写回I/O。当Mike被问到他们是否使用跟踪点时，回答是“是的”，但是，自然 的，google使用的是自己的一套跟踪方法。
google内核改进在2010年还有很多重要的目标：
google对CPU限制功能很兴奋，通过此功能，就能给“低延时任务”较高的优先级，而不必担心这些任务把霸占整个系统。
基于RPC的CPU任务调度，这包括监控RPC入口流量，以决定唤醒哪一个进程。（这很有分布式OS的味道）
延迟调度。对很多任务来说，延迟并不是什么大不了的事。但当RPC消息到来时，内核却尝试去运行所有这些任务；这些消息不会分布到不同的CPU上（意思就是处理这些请求的服务进程可能就在某几个CPU上运转），这造成了系统负载在CPU间分配的问题。所以任务应该能被标为“延迟调度”；当被唤醒后，这些任务并不会被直接放到运行队列上，而是等待，知道全局的CPU负载调度完成。
插入空闲周期。高级电源管理使google能够把服务器用到接近烧毁的边缘——但是不超过这个边缘。
更好的内存管理已经列入计划，包括统计内核的内存使用。
“离线内存”。Mike强调想买到便宜好用的内存是越来越难。所以google需要能够把坏内存标出的功能。HWPOISON兴许可以帮到他们。
在网络方面，google希望改进对“接收端缩放”的支持——即把输入流量导到指定的队列。google还需要统计软件中断次数然后转给指定的任务——网络进程通常包含大量的软中断。google已经在拥塞控制上做了很多工作；他们开发了“网络不安全”的拥塞算法，该算法在google的数据中心运转良好。名为“TCP pacing”的算法放慢了服务器的输出流量，避免了交换机过载。
（自己管理数据中心的公司就是不一样，网络优化做得很细）
在存储方面，google花了大量精力降低块设备层的瓶颈，这样就能更好的使用高速flash。在块设备层通过flash来提高存储效率已经列入了开发计划。google考虑在内核里增加flash转换层，但大家建议google还是把操作flash的逻辑直接放入文件系统层更好一些。
Mike最后总结了几个“感兴趣的问题”。其中一个是google希望把文件系统的元数据固定在内存里。目的是减少I/O请求的时间。从硬盘读取一个块的时间是已知的，但是如果元数据不在内存中，就会有不只一个I/O操作被执行（会有新的I/O操作用来读元数据）。这样就减慢了读文件的速度。google目前对此问题的解决方案是直接从原始块设备读取数据到用户空间（估计是用O_DIRECT，然后自己在用户态管理元数据缓存，这样就不会使用系统的cache），但以后不想 再这么做了。
（不知道google所说的filesystem metadata到底指哪些数据，因为不同的文件系统，metadata也很不同，既然google说要把这些数据固定在内存里，估计应该不大，那自己缓存有什么不好？希望有机会可以问问Mike）
还有一个问题，使用fadvise会降低系统调用的性能。目前还不清楚问题的细节。
google的这个演讲很成功，linux社区也从自己最大的客户那里学到了不少东西。如果google更加面向linux社区的计划能够付诸行动，那linux将会拥有一个更好的kernel。
（注：google可算是IT公司中使用linux最多的，也很可能是使用得最深的，30个人的内核开发队伍，非常可观。看看国内，很少公司、很少人为开源做过贡献，唉，说起来惭愧，在下也是之一啊。）
前一阵的周末，电影台又放了《青蛇》，我和老婆又完整看了一遍。天，从我读高中到现在，已经记不清这是第几遍看了，但不管是第几遍，我依然十分喜欢徐克的
这部惊艳之作。《青蛇》的画面是徐克所惯用的“浓妆艳抹”型，很符合原著的神话风格；音乐出自大师黄沾之手（什么？不知道黄沾是谁？《沧海一声笑》、《男
儿当自强》、《我的中国心》....总知道了吧），古典柔美且诡异，影片开始的一段“人生如此”，更是如怨如诉；主演是当时如日中天的王祖贤、张曼
玉，和咄咄逼人的俊朗小生赵文卓。几方面的天作之合，成就了我认为的徐克电影的最高水平。记得高中时第一次看，觉得天哪，神话片可以拍的这么妖异、精彩、
大气，大陆的神话片和它相比，简直就是小儿科！
《青蛇》拍摄于上个世纪90年代，那时是香港电影的黄金时代，各种题材、各种风格的电影层出不穷，武有成龙，文有张国荣，帅有梁朝伟，靓有王祖贤，武侠、 警匪、枪战、神话、平民各类电影俱全。而今，香港电影风光不在，除了黑帮片还是黑帮片，光“卧底”这一个题材就拍了十几部，演员导演还不重复，真是前仆后 继到了令人发指的地步——曾经大师辈出的香港电影界现在连个写剧本的都没有了吗？！！
黄沾大师已驾鹤西去，王祖贤、张曼玉也已退隐，唯有“老怪”徐克还在继续他的导演之路。
祝福徐克，愿他以后也能像在《青蛇》中那样一展他的鬼才。愿他的才华如他的神怪片一般，不老。
《青蛇》开篇曲 “人生如此”
=====2009.11.8分割线=====
今天才发现《青蛇》的配乐除了黄沾，还有雷颂德....算了，不管他，两人一起纪念一下。
《青蛇》拍摄于上个世纪90年代，那时是香港电影的黄金时代，各种题材、各种风格的电影层出不穷，武有成龙，文有张国荣，帅有梁朝伟，靓有王祖贤，武侠、 警匪、枪战、神话、平民各类电影俱全。而今，香港电影风光不在，除了黑帮片还是黑帮片，光“卧底”这一个题材就拍了十几部，演员导演还不重复，真是前仆后 继到了令人发指的地步——曾经大师辈出的香港电影界现在连个写剧本的都没有了吗？！！
黄沾大师已驾鹤西去，王祖贤、张曼玉也已退隐，唯有“老怪”徐克还在继续他的导演之路。
祝福徐克，愿他以后也能像在《青蛇》中那样一展他的鬼才。愿他的才华如他的神怪片一般，不老。
《青蛇》开篇曲 “人生如此”
=====2009.11.8分割线=====
今天才发现《青蛇》的配乐除了黄沾，还有雷颂德....算了，不管他，两人一起纪念一下。
还以为lvs天然支持failover，后来才发现，如果real server宕机了，只能靠用户层的程序来发现并通过ipvsadm将其删除。
参考：http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.failover.html
参考：http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.failover.html
主要参考http://blog.chenlb.com/2009/06/install-haproxy-and-configure-load-balance.html
我的haproxy配置结果如下：
global
log 127.0.0.1 local0
#log 127.0.0.1 local1 notice
#log loghost local0 info
pidfile /tmp/haproxy.pid #pid文件
maxconn 200
ulimit-n 1024
daemon #作为daemon启动
nbproc 4 #且启动4个haproxy进程（企图把4核cpu用干净）
#debug
#quiet
defaults
log global
mode http
option httplog
option dontlognull
option forwardfor
option redispatch
retries 3
balance leastconn #负载均衡算法采用“最少链接者先处理”
stats uri /ha-st
contimeout 5000
clitimeout 50000
srvtimeout 50000
listen web_proxy1 0.0.0.0:1180 #侦听virtual server的1180端口
server app1 10.254.2.197:80 weight 3 check #第一台real server
server app2 10.254.3.142:80 weight 3 check #第二台real server
#server app3 10.254.3.143:80 weight 3 check
我的haproxy配置结果如下：
global
log 127.0.0.1 local0
#log 127.0.0.1 local1 notice
#log loghost local0 info
pidfile /tmp/haproxy.pid #pid文件
maxconn 200
ulimit-n 1024
daemon #作为daemon启动
nbproc 4 #且启动4个haproxy进程（企图把4核cpu用干净）
#debug
#quiet
defaults
log global
mode http
option httplog
option dontlognull
option forwardfor
option redispatch
retries 3
balance leastconn #负载均衡算法采用“最少链接者先处理”
stats uri /ha-st
contimeout 5000
clitimeout 50000
srvtimeout 50000
listen web_proxy1 0.0.0.0:1180 #侦听virtual server的1180端口
server app1 10.254.2.197:80 weight 3 check #第一台real server
server app2 10.254.3.142:80 weight 3 check #第二台real server
#server app3 10.254.3.143:80 weight 3 check
（转载自《unix编程艺术》）
一学生对无名师说：“我们听说SCO公司把握着纯正的Unix。”
无名师颔首。
学生继续说，“我们还听说OpenGroup公司也把握着纯正的Unix。”
无名师颔首。
“这怎么可能？”学生问。
无名师答道：
“SCO确实把握着Unix源码，但是Unix的源码不是Unix。OpenGroup确实把握着Unix的名称，但Unix的名称不是Unix。”
“那么，什么是Unix传统？”学生问。
无名师答道：
“非源码。非名称。非思想。非实物。恒变。不变。”
“Unix传统是简单和空。正是简单，正是空，才使得它更强胜飓风。”
“以自然法则前行，在程序员手中，吸纳各种优良设计。与之竞争的软件最终必与之想像；空，空，真空，虚无，万岁！”
听到此，学生眼中一亮。
一学生对无名师说：“我们听说SCO公司把握着纯正的Unix。”
无名师颔首。
学生继续说，“我们还听说OpenGroup公司也把握着纯正的Unix。”
无名师颔首。
“这怎么可能？”学生问。
无名师答道：
“SCO确实把握着Unix源码，但是Unix的源码不是Unix。OpenGroup确实把握着Unix的名称，但Unix的名称不是Unix。”
“那么，什么是Unix传统？”学生问。
无名师答道：
“非源码。非名称。非思想。非实物。恒变。不变。”
“Unix传统是简单和空。正是简单，正是空，才使得它更强胜飓风。”
“以自然法则前行，在程序员手中，吸纳各种优良设计。与之竞争的软件最终必与之想像；空，空，真空，虚无，万岁！”
听到此，学生眼中一亮。
