yum复活

今天想用yum安装一个新的包,但是忽然发现yum命令一执行就hang在那里。Ctrl+c都没法退出,只能kill -9。

查看了网络连接,也一切正常。

后怀疑也许是rpm db有问题,使用rm -f /var/lib/rpm/__db*清空rpm db数据。

然后用rpm -vv –rebuilddb重建数据库。

最后yum clean all把yum用到的cache都清空。

一切就又恢复正常了。

戏说Linux-2.6.38中进程调度的优化

2.6.38?现在2.6.37还在RC中,怎么会有38?是的,因为37进了RC,所以不会再加新功能了。那么将要进入的新功能只能放到38中。而谁会是2.6.38的闪光点呢?对于进程调度subsys来说,很有可能就是autogroup了。

虽然现在这个新功能还在讨论中,但是Linus和Ingo都已经buy in得差不多了,进入main tree是指日可待了。这个feature要说最早也是来自于Linus的灵感,其实很多人应该也多有感受。比如在我们编译内核时,桌面响应就会变慢,甚 至在vi里敲个字都顿啊顿的;再比如在emule下载完一部电影后做sync时,大量IO也会拖得桌面很顿。这是由于进程调度器在选择下个需要被调度进程 时对于需要快速响应的进程没有做到充分考虑其特殊性。但是你要是用过Redhat9的话,一定会感觉现在Linux的桌面响应或是普通tty响应都快太多啦。这完全要归功于Con Kolivas 和Ingo的不懈努力得到的CFS(虽然Con在技术论战中败下阵后一蹶不振,回去干麻醉师的老本行了;但在论战中胜出的Ingo把sched维护的有 声有色),CFS的完全公平调度天性,让编译程序等非交互性进程被调度器选择时的优先度大大降低(运行的时间越多,在RB tree中越靠边;而运行时间及机会越少的交互式进程越有机会靠近RB tree的左下角,这个左下角可是黄金地段啊,调度器就喜欢从这个地方调进程了)。这么看来CFS做的也很好了,但是在这个牛人辈出的时代,Mike Galbraith站了出来,大声的说,我还可以让交互进程响应更快!

凭什么这么说?凭cgroup!说到这个cgroup,对笔者来说算是老朋友了,或者说是老朋友的老朋友了。国内的Linux新一代牛人中的一位Zefan LI是我的老兄弟,而他恰恰又是cgroup的maintainer,2008年时国内的少数几位内核维护者之一。cgroup是干嘛的呢?google 搜一下,有功底的朋友应该可以看懂,我在这里简单解释,相信也能让大家有个概念。想象一下有这么种容器,你可以把进程放入其中,并给这个容器贴个标签,比如:“核心业务进程”,“娱乐用进程”,“老婆用的进程”等等。并且你可以拿个更大的容器,把“娱乐用进程”和“老婆用的进程”的小容器都扔到那个大容器中,并贴个标签“家用进程”。cgroup就是用来定义这些容器的框架。有了它,我们可以让“核心业务进程”的容器内的进程享有一些特权,比如说固定的网络带宽,较大的IO速度等;我们还可以让“老婆用的进程”容器里的进程只得到很少的系统资源,哈哈,床上打不过你,我还不能靠我的拿手本领整你!(这里的我,泛指天下受苦受难的男性软件工程师)

废话少说,就要到正题了,看到这里,就算你不是Mike G,你也该知道怎么整了吧?虽然知道怎么整与能整出code来还是有差距的,但是至少我们也想到啦。Mike的做法果然不出我们所料,具体说,就是在进程需要用到tty资源时,比如说vi啦,gedit啦,魔兽世界啦。。。。(魔兽世界在Linux上还能玩啊?)就把它放到一个特殊的容器中,这个容器贴了标签“老子要快点响应”。那么进程调度器在挑选下一个家伙来使用CPU时,就会乖乖的去找它啦。就这么简单。简单?你去写一个!

Mike只用了一个220行左右的patch就做到了,代码极尽精炼无耦之能事,被Linus开心的表扬了一遍又一遍。不过最厉害的还是让数据说话,调度平均响应时间为原来的16分之1左右。厉害吗?太厉害了。但是。。。

对的,什么事都会有但是,这是唯物辩证法告诉我们的。cgroup对系统是有penalty的。你想啊,本来人家进程们好好呆在红黑树上等着调度,你非得再给人家按容器分分类,贴贴标签,等到调度器来拉壮丁去享受CPU或其他资源时,不仅得去树里挑,还得在一堆罐子中挑,最可恨的是罐子里还套着罐子。这个Linus当然也是一针见血的就看出来了,可Mike不愧是小牛人。立马拿出准备已久的理由说,对于缺少人机交互的server来说,这个确实比较扯淡(其实也还好啦,cgroup不会带来大于5%的开销),但是对于那些装了Fedora,Ubuntu等等的桌面用户来说,根本无法感知cgroup的开销,反而会乐意接受基于cgroup的autogroup带来的高速响应。厉害!

厉害归厉害,社区里厉害而又爱挑刺(追求完美啦)的人多得是,所以Mike同志还在矜矜业业根据大家的建议做些细微的改善,细微却很重要的改善,估计进Ingo的sched tree是没问题了。热切期待其正式进入2.6.38,接受大众的考验。

站点恢复了

万网实在太烂了。说php进程占了虚拟主机很多资源,居然把站点关掉了。感谢intscan的Byron给我提供了新的宿主。

不过在mysql数据迁移过程中还是遇到了一些问题。

1. 高版本的php不支持global_register,导致大量php页面出错,改了php.ini很偷懒的绕过这个问题。

2. 这里的php默认没装图形库php-gd,导致patch的图形统计页面无work,装php-gd搞定。

3. 这里的mysql默认collation为latin,导致blog的中文乱码,改collation为uft-8即可。

Intel买咖啡,太渴了

It could be a brilliant move, or a huge mistake, and only time will tell.

读了Intel和McAfee的官方blog,对此次收购的双方意图解析如下:

Intel:结合安全厂商,扩大无线设备的战略。这次收购咖啡是组合拳中的第二拳。第一拳来自对Wind River的收购,Wind River是嵌入式软件厂商,在被收购后即推出Secure Embedded Linux,这次收购咖啡应该是对Security的再次补充军力(从Linux内核patch可以看出McAfee在嵌入式安全领域一直有所投资,并收购过secure computing,cyberguard, snapgear 等公司)。

无线设备是Intel的支柱之一,而显然现在多元化的终端设备中移动嵌入式设备是主力,而且移动嵌入式设备也给安全领域带来新的挑战,作为硬件厂商的Intel结合成熟安全厂商的技术,很想在移动设备安全领域有所进展,同时促进Intel的移动设备战略。

McAfee:对于安全领域的循序渐进不再满足,希望通过软硬结合来弥补安全领域中攻方和守方的gap。这是McAfee CTO的解释。但是我的理解是,借用Intel硬件铺平的渠道,平台,市场来大展安全的身手才是她的重要意图。现在看来,合并暂时会更多利于面向consumer的终端安全,但可以预见移动设备会通过商务领域渗透入企业领域,从而影响到企业安全相关产品。

总的来说,个人理解这次收购对于Intel是一小步,对于McAfee是一大步,双方能否同步期望值,达到真正双剑合璧,我持观望态度。从技术上看,软硬结合的安全策略也没有想象中那么容易达到。

Receiving Packet Steering

Linux Kernel 2.6.35最赞的feature就是RPS。

现在的网卡可以接收/发送包的速度已经开始让宿主机的CPU难以跟上。而由于单个CPU的处理能力也慢慢变得难以提升,那么把数据包分布到多个CPU上处理就变得很有必要。在2.6.35内核中,来自Google的Tom Herbert提交了RPS的系列patch,实现了此机制。(对于发出的数据包,已经不存在这样的问题了,因为发送数据包的进程本身就是分散在CPU上运行的。)

Tom的实现非常简单,在netif_rx()和netif_receive_skb()这两条内核收包必经之路上做了以下处理:

  1. 为每个包做一个hash(根据源IP,目标IP,端口)
  2. 根据hash把包放入相应CPU的backlog队列
    • 用户可以通过/sys/class/net/<device>/queues/rx-<n>/rps_cpus设置一个mask,指定特定网卡或者网卡上的某个接收队列(如果支持多接受队列的话)可以包交给特定的几个CPU处理。
    • 包的hash值和rps_cpus的值共同决定了该数据包会放入哪个CPU的backlog队列。

经过以上修改,内核可以支持:

  1. 为网卡或网卡上的接收队列指定数据包可以在哪些CPU上被均衡处理。
  2. 来自网卡的数据包不再被一个CPU的计算瓶颈限制,可以被分布到多个CPU上处理接收。
  3. 由于hash值是根据源IP,目标IP和端口计算得出,因此同一个transaction的包被同一个CPU处理,可以达到很好cache命中率,从而提高性能。

Google的生产线上已经使用了RPS,效果不错。这里是Tom给的一些测试数据,明显看到CPU利用率提升以及网络PPS和TPS的提升。

e1000e on 8 core Intel
Without RPS: 108K tps at 33% CPU
With RPS:    311K tps at 64% CPU

forcedeth on 16 core AMD
Without RPS: 156K tps at 15% CPU
With RPS:    404K tps at 49% CPU

bnx2x on 16 core AMD
Without RPS  567K tps at 61% CPU (4 HW RX queues)
Without RPS  738K tps at 96% CPU (8 HW RX queues)
With RPS:    854K tps at 76% CPU (4 HW RX queues)

但是同时,这里有一些limitation。

  1. 一个数据包到达后,中断所到达的CPU负责分配,这时会通过SKB内容计算hash,由于是第一次读这个SKB,所以发生cache miss正常。但是之后这个数据包可能会被分配到其他CPU上处理,对于另一个CPU来说,SKB仍然是一个未知内容,所以cache miss又会发生,这次的cache miss就是RPS带来的新开销。不过幸好,很多网卡都天生支持计算这样的hash,驱动只需要把该值存入SKB,就可以提高cache hit,以及计算机整体性能。
  2. rps_cpus可以在运行时被动态改变,但是这样的改动可能会导致包的乱序。因为改动前某个transaction的数据包都是由某个CPU处理,而rps_cpus改变,可能导致该transaction的包被发往另一个CPU上处理,如果后到的包在第二个CPU上被处理的速度快于先到的包在第一个CPU上被处理的速度,就会发生乱序。所以尽可能不要频繁改变rps_cpus的值。

Setup IPv6 tunnel on Linux

On Fedora 11, install miredo first.

# yum install miredo

Then launch miredo by root account.

#/usr/sbin/miredo

Now you have a new network interface “teredo”

Then you can do “ping6 -c 4 ipv6.google.com” or use browser to access http://ipv6.google.com.

It’s simple haah.

But be noticed that some ISP add extra head when do DNS, you can use google’s public DNS “8.8.8.8″ instead.

Good Luck.

低成本电影-The Man from Earth

假如一个人告诉你他活了14000年,经历了冰川期,见过猛犸象,追随释迦摩尼学习佛法,为了传播佛教成为了耶稣,跟哥伦布一起航海,和梵高打过交道。你一定 会认为这个人来自科幻小说。是的,和吸血鬼一样,这个男人不会衰老,永远停留在35岁,100年虽然是他经历过的1/140之一,但是他却不能像我们回忆1年前的事情那样回忆一百年前的事。他有过无数次的爱情,但都没有他的生命那么永恒。他已经不记得他的父亲的模样,人类中有1/10可能都是他的后代。

生命的永恒在这部电影里看起来不那么美好,虽然凡人对此羡慕不已。

片中的所有出场人物是8个(另外还有两个搬运工,出场10分钟),从头到尾就是个谈话节目,场景只有一个小屋及屋外一些片段。

Chuck Norris – 小心的你冰箱中毒

最近很多基于MIPS+Linux的路由器和DSL Modem被一种叫做Chuck Norris的病毒感染。Chuck Norris侵入路由设备的原理很简单,通过Linux本身漏洞以及一般用户不修改路由设备默认密码的习惯,在路由设备的RAM中驻留并取得root权限。侵入后,Chuck Norris可以利用路由设备或者设备后端的计算机对其他网络发起DDOS攻击。它还可以改变DNS,让终端对域名的访问指向有害IP。

看官如果想要搜索Chuck Norris相关信息时,不要搜索“Chuck Norris”,因为它和美国的电影演员查克·诺里斯(空手道世界冠军,《猛龙过江》中在古罗马竞技场与李小龙搏击)同名。请搜索“Chuck Norris router” J

病毒每天都有,Linux病毒也不是第一次有了,看来也没有什么好惊奇的。但是Chuck Norris还是给笔者敲响了警钟。互联网安全已经不单单是计算机安全的问题了,智能设备的安全堡垒也在慢慢被攻破。IP-TV也许很快就是下一个被攻击对象了,接下来就是接入网络的家电设备。就像禽流感不单单感染鸟类同时还感染人类一样。

另外,随着云的发展,计算终端会慢慢泛化,各种接入设备都可以成为云终端,那么谁来负责设备安全呢?计算机安全只是个小蛋糕,设备安全的蛋糕会更大。