软件开发: 01 2011存档

写了一个用于rpm打包装包的spec文件，大概如下：

%post

insmod hello.ko

%postun

rmmod hello.ko

%post段​​​​​里是在rpm安装完成后执行​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​的脚本，%postun段则是在rpm包卸载后执行的脚本

现在，这个rpm正常工作，安装后会自动加载hello.ko，卸载后会自动移除hello.ko

但是，麻烦出现了，当我们用yum来update这个包时，发现包在update后居然没有加载hello.ko。原来，yum的update操作实际执行了（假设旧包叫old_pack，新包叫new_pack）：

1. new_pack %install

2. new_pack %post

3. old_pack %postun

在新包%install和%post执行后，旧包才执行%postun，结果，新包刚insmod的hello.ko，旧包的%postun把它给rmmod了。yum这样执行有它的道理：new_pack万一执行失败，还能回滚。

那么，这个%postun要怎么写呢？

查了半天，终于找到了一篇文档 http://www.ibm.com/developerworks/library/l-rpm2/ ，感谢Martin Streicher同学的详细介绍。

只要在%postun里判断第一个参数的值，就可以知道现在是执行update还是在执行uninstall，于是，正确的spec应该是

%post

insmod hello.ko

%postun

# if uninstall then rmmod

if [ "$1" = "0" ]; then

    rmmod hello.ko

fi

这样，在update的时候，就不会误卸载hello.ko了。

前段时间同事搞来了一台使用tilera处理器的服务器，没错，就是那个由MIT专家做的、64个核的处理器，我非常好奇，所以也登上去体验体验。

tilera在硬件之上做了一个薄薄的软件层，叫hypervisior，再在这个hypervisior上装了一个linux，然后是gcc/g++/gdb等一套工具链。当然，这个linux是改过的，在内核arch/tile/目录里增加了东西，但是即使是增加了kernel代码，也只能跑在hypervisior上，不能直接跑在tilera硬件上。

我们用的是tilepro处理器，32位，64个核，每个核却只有863MHZ，所以多进程/多线程的程序有福了，我试了一下make -j60，感觉上确实比较快，但是，configure就慢得夸张。

在tilera上安装apache+php的过程中遇到几个小问题，主要是因为这个linux环境比较荒芜：

1. 从源码安装软件时，运行./configure遇到“configure: error: C compiler cannot create executables”,解决方法：

export CC=”gcc”

export CPP=”gcc -E”

2. ./configure还会遇到不能识别当前机器的处理器类型，解决方法：

./configure --build=i386

不用担心这个欺骗性的i386选项，对于可移植的c代码软件，这样不会造成什么问题。

我安装php最后还是失败了，所以拉倒，改装nginx做测试，起了20个nginx进程，通过千兆网卡做压力，却只能达到3000左右的QPS，这显然太低了。于是问了tilera的技术支持，他反馈说他们做过memcached的实验（据他说，facebook已经在用tilera机器专跑memcached），能到60万QPS，但是nginx多进程却很慢，他们也很疑惑，目前还在研究为什么。

看来tilera的软件层目前还偏薄弱，等一段时间吧，等linux-2.6.36稳定，且tilera的3.0版本的开发工具套件变为stable，我们再来关注关注。

====== 2011.01.06 ======

今天tilera公司的顾冉同学发来新消息，他们就用和我们一样的硬件环境（一片tilepro）和软件环境（MDE-2.1.0），10个左右的并发nginx，达到了将近2万QPS，比x86上的apache差一些，但是比我的测试结果已经好很多了。

也许是我的配置有问题，有待以后研究了。