记得在PHP开发过程中，经常会用到实例级别或者线程级别的变量缓存，带来的性能提升是巨大的。但对于tornado来说，由于每次访问都会实例化tornado.web.RequestHandler，不能满足要求，只能考虑在主线程上进行变量缓存。一旦成功将有可能直接抛弃redis。

种种原因，不公开最终实现的代码，这里只用一个页面计数器来模拟。通过一个页面http://localhost/get获得主页http://localhost/的Page View。

import tornado.httpserver
import tornado.ioloop
import tornado.options
import tornado.httpclient
import tornado.web
import sys, os
from tornado.options import define, options

#####
class PageCounter(object):
    count = 0
####

#PageCounter = 0 这种采用全局变量的方法被证实无法实现。

class MainPage(tornado.web.RequestHandler):

    def get(self):
        PageCounter.count += 1
        self.finish('Hello World!')

class GetPageView(tornado.web.RequestHandler):
    def get(self):
        sPageView = str(PageCounter.count)
        self.write(sPageView)

def main(port):
    if os.fork() != 0:
        exit()
    define("port", default=port, help="run on the given port", type=int)
    application = tornado.web.Application([
        ("/", MainPage),
        ("/get", GetPageView),
    ])
    http_server = tornado.httpserver.HTTPServer(application)
    http_server.listen(options.port)
    tornado.ioloop.IOLoop.instance().start()

if __name__ == "__main__":

    if len (sys.argv) > 1:
        port = sys.argv[1]
    else:
        port = 80
    main(port)

这里要说的是object基类的PageCounter方法，可以定义一种数据结构以及对应的操作方法。当然这段代码只是Demo，写得不规范。由于PageCount是全局的，跟随进程实例化，所以可以很灵活在各个实例之间传递数据。

类似这种方法，我们的项目性能提升了至少5倍。但这样实现的结果也非常明显，首先不能持久化，一旦进程终止，数据就被清空；其次是进程隔离，这种方法共享数据只能工作在tornado的一个进程中，对于习惯于多进程并行的Tornado部署会有问题，我们最终的做法是做唯一哈希；最后要注意的是内存释放的问题，数据保存在内存中，如果是大量的数据通过dict/list做映射的话需要进行定期清理，当然通过这种方法可以变态的做一个基于HTTP协议的Key-value数据库。

# ab -n10000 -c1000 http://localhost/
This is ApacheBench, Version 2.3 < $Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests

Server Software: TornadoServer/2.1.1
Server Hostname: localhost
Server Port: 80

Document Path: /
Document Length: 12 bytes

Concurrency Level: 1000
Time taken for tests: 8.921 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 1700000 bytes
HTML transferred: 120000 bytes
Requests per second: 1120.89 [#/sec] (mean)
Time per request: 892.148 [ms] (mean)
Time per request: 0.892 [ms] (mean, across all concurrent requests)
Transfer rate: 186.09 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 230 792.8 0 3012
Processing: 14 134 73.9 114 1878
Waiting: 14 134 73.9 114 1878
Total: 86 364 815.1 114 3818

Percentage of the requests served within a certain time (ms)
50% 114
66% 115
75% 121
80% 141
90% 378
95% 3135
98% 3176
99% 3223
100% 3818 (longest request)

从小站一开始就在思索如何与用户互动，评论自然是一个好的方式。但访问本站的朋友大多数是在处理问题时通过搜索引擎进来的，看一眼就走人，可谓是“来也匆匆，去也匆匆”自然不会有评论。即便是文章中的错误，除了背后骂娘之外也不会有其他的动作。当然也有很多的评论，几乎占了90%以上，无非还停留在某某论坛的抢积分逻辑上。“顶”，“路过”等等没什么营养的回复我会直接归结为垃圾评论。

作为ITer，我本身非常热衷于新事物，微博这类的新媒体我也用了一段时间。当然09年前以Twitter为主，众所周知的原因，不能成为主流。后来用了Google buzz，最大的优点在于可以直接与Google Reader中的feed订阅同步。可惜google自己终止了它。最终只能回归到GFW内的本地克隆。抵制腾讯的我选择了新浪微博。

@开源微站 敬请关注！

再此之前，还是先确认系统的CPU是否支持虚拟化：
#egrep ‘(vmx|svm)’ /proc/cpuinfo

应该有返回，如果没有返回，且确认您的CPU支持虚拟化的话，建议去看看BIOS设置，大多数的主板都支持关闭此技术的。

还是以最常用的Ubuntu Server 做例子，desktop的可以直接apt-get install ubuntu-server之后，用server的核心启动。如果你全程参考本文，个人建议还是通过后一种方式来做，因为本文的过程需要X环境。

首先，设置好桥接，由于我使用的机器在远程，操作全部通过ssh，桥接的过程断开过网络。让机房重起数次之后，找到了最稳妥的方法，虽然也要断网，但好在会自己恢复。

#sudo apt-get install bridge-utils uml-utilities

#vi /etc/network/intefaces

auto lo
iface lo inet loopback

auto tap0
iface tap0 inet manual
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
tunctl_user root

auto br0
iface br0 inet static
bridge_ports eth0 tap0
address 192.168.1.3
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.254

注意这个br0，我通过前端防火墙做的DMZ通道，所以设置了内网地址。主机通过这个ip访问。所有的虚拟主机也直接设置到192.168.1.0/24网段。

#/etc/init.d/network restart

断网了，等待几分钟后网络恢复，直接ifconfig

br0       Link encap:Ethernet  HWaddr 02:0b:b1:f7:79:01
inet addr:192.168.1.3  Bcast:192.168.1.255  Mask:255.255.255.0
inet6 addr: fe80::b:b1ff:fef7:7901/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:506941 errors:0 dropped:0 overruns:0 frame:0
TX packets:733910 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:45469237 (45.4 MB)  TX bytes:654152049 (654.1 MB)

eth0      Link encap:Ethernet  HWaddr e4:1f:13:95:82:cf
inet6 addr: fe80::e61f:13ff:fe95:82cf/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:1367878 errors:0 dropped:0 overruns:0 frame:0
TX packets:1541493 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:689206805 (689.2 MB)  TX bytes:1062795975 (1.0 GB)
Memory:81a80000-81aa0000

eth0:0    Link encap:Ethernet  HWaddr e4:1f:13:95:82:cf
inet addr:192.168.1.2  Bcast:0.0.0.0  Mask:0.0.0.0
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
Memory:81a80000-81aa0000

桥接成功！

相对来说，我还是比较喜欢图形化的管理工具，命令行实在太痛苦

#apt-get install virt-manager libvirtd kvm libvirt-bin

看看是否安装成功

# ls /dev | grep kvm

直接用ssh通道执行gnome-session就可以连到远程桌面，执行系统工具里的“虚拟系统管理器”。添加连接中选择本地，QEMU/KVM。

然后建立新的虚拟主机，个人觉得这块跟用VM之类的工具没有什么区别了，直接跳过了。不过在第五步的时候，请将网卡设置为桥接设备，除非仅仅用于NAT方式联网。

需要注意的是，如果你跟我一样通过远程连接，直接打开主机的控制台的时候，键盘会不听使唤。这不是切换键盘设置可以搞定的问题，我尝试过不同的X客户端和操作系统，涵盖了windows mac linux，全都如此。只能认为是一个bug。我的最终解决方法是通过ssh通道，将远程主机的5900 VNC端口转接回本地，然后再通过vnc客户端连接本地才得以通过，键盘的问题得以解决。很傻，如果你有更好的方式，敬请赐教了！

照旧建立一个虚拟主机，我还是选择了Ubuntu Server 1110 64bit，也没有什么好说的。安装好之后，配置好了ssh。从此就可以直接抛弃vnc和宿主主机的X访问了。

在虚拟主机上安装定制的内核:

#apt-get install kernel-virtual

重起的速度那是嗖嗖的！直接lsmod发觉真的是定制内核，和标准的server内核比起来一点多余的没有：

root@www:~# lsmod
Module                  Size  Used by
psmouse                73882  0
serio_raw              13166  0
lp                     17799  0
parport                46562  1 lp
8139too                32177  0
8139cp                 27412  0

对比一下性能吧，还是那道题目的python原版，稍作优化：

虚拟机：

root@www:/home/litrin# python TimeCost.py
10240
Cost: 0.508388996124
root@www:/home/litrin# python TimeCost.py
10240
Cost: 0.507208108902
root@www:/home/litrin#

宿主机：

root@vserver:~# python TimeCost.py
10240
Cost: 4.35039806366
root@vserver:~# python TimeCost.py
10240
Cost: 4.35194683075

我开始真的不知道该如何解释。虚拟机的性能竟然强于宿主机。后来检查了python的版本才明白，宿主是py2.6而客户机是2.7，版本不同，性能有差距，但可以肯定的是，从这一点上来说虚拟化的性能损失不大。

最后一步，去掉虚拟机上不需要的东西，精简主义者！

这次就直接用宿主的命令行操作吧：

#virsh

virsh # list
Id Name                 State
———————————-
30 www.litrin.net       running //我的虚拟主机名为www.litrin.net，请注意！

virsh # edit www.litrin.net

删掉vnc, pty, mouse, graphic

virsh # destroy www.litrin.net

virsh # start www.litrin.net

这里有一个问题也凸现，就是无法使用宿主机的reboot和halt命令，只能强行的destroy。

你同时还可以配合DHCP和主机克隆，大规模快速甚至自动化的架设多个虚拟机，本文不再探讨。

尽管现在“云”已经被用滥了，搞个虚拟机就敢号称云托管的大有人在。个人觉得其实对于少数几台主机的虚拟化来说，更多的是节约机房的托管费用和主机成本，这对于稍微大一点的项目并没有什么太多的优势。如果配合上open stack之类的故障平滑迁移技术才是虚拟化方案的终极利器。

作为No-sql的强项，MongoDB的数据分发/同步机制相对比MySQL灵活的多，支持传统上的主从同步和趋向于高性能的ShareSet，而且对于程序端来说改动相对较小，代价几乎可以不计。现在就从这两种分发机制方式说起。

Master-slaver机制

不同于MySQL的主从同步，MongoDB的主备同步有3种角色，primary（相当于Master）, secondary（相当于Slave），Arbite（选举机）。正常情况下primary与secondary的配置要相当，因为很有可能主备切换，Arbite则没有被升格的可能（只有选举权，没有被选举权），正常情况下只是相当于一个心跳监控机而已。一旦p出现故障或者整个拓扑结构发生变化，导致P不能联系上大多数M之后，如果存在多台S需要升格成P的时候就需要A来进行选举。

Master-Slaver的部署

假设3台主机,主机名分别是 P S A,请注意Shell提示符

P# mongod –rest –replSet testSet

P# mongo

>cfg = {member:{host: “P:27017″}}
>  rs.initiate(cfg)

S# mongod –rest –replSet testSet
p#mongo

>rs.add(“S”)

{ “ok” : 1 }

A# mongod –rest –replSet testSet –oplogSize 8

p# mongo

>rs.add( { host:”A”, arbiterOnly:true } )

{ “ok” : 1 }

宣告成功！就这么简单！

如果之前一直按照此步骤的话，你就可以直接通过访问http://P:28017/来查看整个系统的状态。

理论上MongoDB可以支持互为主备，但个人觉得没有意义，反而会出现较多的一致性问题，没有在这里测试。

Sharding机制

不知道你会怎么理解”Sharding”这个单词，我的第一反应是罐头装的沙丁鱼。从拓扑结构上看，真的很像！

沙丁鱼有3种角色，shard，参与存储和运算的节点，要求数量多；config ，控制节点，保存有各个数据的哈希映射，及负载信息,相对来说是整个环节中的关键应用；mongos，路由节点，负责前端分发和数据汇总，相对来说是整个环节中的中央应用。客户端向任意一个Mongos发起请求，mongs首先从config上获取哈希映射，再通过哈希映射获取所有的数据后汇总给客户端。config不断的维系全局的数据分片，又有点类似心跳监视的意思。更加夸张的是，这种沙丁鱼结构支持嵌套，同样也支持嵌套上面的主从结构。

sharding的部署

这次还是3台机器，S1 S2 MS，S1 S2在做shard服务器的同时也兼作config，shard是27018口，config是27019口，都是默认的端口。

s1# mongod –shardsvr –replSet s1

s1# mongo

> cfg = { _id : “s1″, members : [ {_id : 0, host : "S1:27018"}, ] }

> rs.initiate(cfg)

s2# mongod –shardsvr –replSet s2

s2# mongo

> cfg = { _id : “s1″, members : [ {_id : 0, host : "S2:27018"}, ] }
> rs.initiate(cfg)

s1# mongod –configsvr

s2# mongod –configsvr

MS# mongos –configdb s1:27019,s2:27019

MS#mongo

> db.adminCommand( { addShard : “s1/s1:27018″ } )

> db.adminCommand( { addShard : “s2/s2:27018″ } )

恭喜完成了这么复杂的系统!需要注意的是整个系统中尽量使用主机名,通过hosts指向还是通过DNS无所谓，这是因为系统一旦启动就很难修改主机信息，IP地址远没有主机名灵活。

客户端的配置

算了,照贴PHP官档！

一直把Python当成胶水语言来用，这次就接着这个话题，说个Python C重构的例子：

首先是python原码：(很眼熟吗？)

#!/usr/bin/env python

import time

lGoal = {}

def main(i):
#    if lGoal.has_key(i):
#        return lGoal[i]

    if i < 1:
        return long (0)
    elif i < 2:
        return long(1)
    return main(i-1) + main(i-2) - main(i-5)

def getList(iMax):
    for i in range(1, iMax+1):
        iGoal = main(i)
        lGoal[i] = iGoal

    return lGoal

#i = int(raw_input())
i = 30
timeStart = time.time()
getList(i)

print "Cost: %s" % (time.time() - timeStart)

看看它的耗时：
Cost: 21.9739699364

首先对于这种多重循环和调用，绝对是C的强项，理论上Python 2 C 之后会有很大的提升空间。重构的思路是用Python的ctypes模块调用基于C的lib库，这样可以在保留大部分Python代码的基础上完成重构，而且重构之后的程序仍然还是Python的。
开始C重构vi LoadTest.c：

#include <stdio.h>
/*
int main()
{
    int i, goal;
    for (i=1; i <= 30; i++)
    {
        goal = C_Time_Cost(i);
        printf ("%d, %d \n", i, goal);

    }

   return 0;
}
*/
int C_Time_Cost(int a)
{
    if (a < 1)
    {
        return 0;
    }
    if (a < 2 )
    {
        return 1;
    }

    return C_Time_Cost( a - 1 ) + C_Time_Cost( a - 2 ) - C_Time_Cost( a - 5 ) ;
}

编译到.o文件：
gcc -c LoadTest.c -fPIC

编译成为Lib
gcc –shared -o libLoadTest.so LoadTest.o
cp libLoadTest.so /lib64 && ldconfig //这一点很重要，否则会报找不到lib文件。

修改python:

#!/usr/bin/env python

import time
from ctypes import *
lGoal = {}

def main(i):
    cdll.LoadLibrary("libLoadTest.so")
    libc = CDLL("libLoadTest.so")
    goal = libc.C_Time_Cost(c_int(i))
    return goal

def getList(iMax):
    for i in range(1, iMax+1):
        iGoal = main(i)
        lGoal[i] = iGoal

    return lGoal

#i = int(raw_input())
i = 30
timeStart = time.time()
getList(i)

print "Cost: %s" % (time.time() - timeStart)

执行时间：
Cost: 0.280420064926

对比之前的21.9739699364 性能提升78倍！不过需要注意，ctypes模块的加载本身很耗资源，使用不当会起到反效果，例如将i=30改为i=10的情况下，python: 0.000591039657593，而Ctypes则需要0.00165605545044，反而落后3倍的时间。

正常情况下，像Redis这样定期回写磁盘的内存数据库，丢失几个数据也是在情理之中，可超过80%数据丢失率实在太离谱。排除了误操作的可能性之后，开始寻找原因。

重启动时的日志：

[26641] 21 Dec 09:46:34 * Slave ask for synchronization

[26641] 21 Dec 09:46:34 * Starting BGSAVE for SYNC

[26641] 21 Dec 09:46:34 # Can’t save in background: fork: Cannot allocate memory

[26641] 21 Dec 09:46:34 * Replication failed, can’t BGSAVE

[26641] 21 Dec 09:46:34 # Received SIGTERM, scheduling shutdown…

[26641] 21 Dec 09:46:34 # User requested shutdown…

很明显的一个问题，系统不能在后台保存，fork进程失败。

翻查了几个月的日志，发觉系统在频繁报错：

[26641] 18 Dec 04:02:14 * 1 changes in 900 seconds. Saving…

[26641] 18 Dec 04:02:14 # Can’t save in background: fork: Cannot allocate memory

系统不能在后台保存，fork进程时无法指定内存。

对源码进行跟踪，在src/rdb.c中定位了这个报错：

int rdbSaveBackground(char *filename) {
    pid_t childpid;
    long long start;

    if (server.bgsavechildpid != -1) return REDIS_ERR;
    if (server.vm_enabled) waitEmptyIOJobsQueue();
    server.dirty_before_bgsave = server.dirty;
    start = ustime();
    if ((childpid = fork()) == 0) {
        /* Child */
        if (server.vm_enabled) vmReopenSwapFile();
        if (server.ipfd > 0) close(server.ipfd);
        if (server.sofd > 0) close(server.sofd);
        if (rdbSave(filename) == REDIS_OK) {
            _exit(0);
        } else {
            _exit(1);
        }
    } else {
        /* Parent */
        server.stat_fork_time = ustime()-start;
        if (childpid == -1) {
            redisLog(REDIS_WARNING,"Can't save in background: fork: %s",
                strerror(errno));
            return REDIS_ERR;
        }
        redisLog(REDIS_NOTICE,"Background saving started by pid %d",childpid);
        server.bgsavechildpid = childpid;
        updateDictResizePolicy();
        return REDIS_OK;
    }
    return REDIS_OK; /* unreached */
}

数据丢失的问题总算搞清楚了！

Redis的数据回写机制分同步和异步两种，

1. 同步回写即SAVE命令，主进程直接向磁盘回写数据。在数据大的情况下会导致系统假死很长时间，所以一般不是推荐的。
2. 异步回写即BGSAVE命令，主进程fork后，复制自身并通过这个新的进程回写磁盘，回写结束后新进程自行关闭。由于这样做不需要主进程阻塞，系统不会假死，一般默认会采用这个方法。

个人感觉方法２采用fork主进程的方式很拙劣，但似乎是唯一的方法。内存中的热数据随时可能修改，要在磁盘上保存某个时间的内存镜像必须要冻结。冻结就会导致假死。fork一个新的进程之后等于复制了当时的一个内存镜像，这样主进程上就不需要冻结，只要子进程上操作就可以了。

在小内存的进程上做一个fork,不需要太多资源，但当这个进程的内存空间以Ｇ为单位时，fork就成为一件很恐怖的操作。何况在16G内存的主机上fork 14G内存的进程呢？肯定会报内存无法分配的。更可气的是，越是改动频繁的主机上fork也越频繁，fork操作本身的代价恐怕也不会比假死好多少。

找到原因之后，直接修改内核参数vm.overcommit_memory = 1

Linux内核会根据参数vm.overcommit_memory参数的设置决定是否放行。

1.  如果 vm.overcommit_memory = 1，直接放行
2. vm.overcommit_memory = 0：则比较 此次请求分配的虚拟内存大小和系统当前空闲的物理内存加上swap，决定是否放行。
3. vm.overcommit_memory = 2：则会比较 进程所有已分配的虚拟内存加上此次请求分配的虚拟内存和系统当前的空闲物理内存加上swap，决定是否放行。

首先，准备2套Redis主机，本例192.168.0.1为主，192.168.0.2为从。为了保障不会出现稀奇古怪的毛病，要求2台主机配置文件中

• databases ，dbs数量，决定了select命令的最大数（分块数量）
• maxmemory，最大内存使用，决定了整个系统的容量

两个参数的配置要一致，系统版本尽量保证一致（我测试过不一致的版本也可以同步，但不保证所有的情况下都可以同步）其余的数据不强制要求一致。

用客户端连接slaver主机的redis并操作

redis-cli -h 192.168.0.2

redis 192.168.0.2:6379> slaveof 192.168.0.1 6379
OK

就这么方便！

这时，可以在输入info命令，查看master_host的配置：

redis 192.168.0.2:6379>info
…
master_host:192.168.0.1
…

为保证主机每次启动都保持slave的状态，则可以在redis.conf中增加一行slaveof 192.168.0.1 6379 即可，也非常简单。

作为redis这类nosql来说，并发的压力并不像MySQL那样迫切，何况数据没有关联，一旦出现并发的瓶颈，可以很方便的将数据拆分成多个主机。那对于标准的web应用，主从的意义是什么？

个人理解：

1. 解决Redis内存回写磁盘一瞬间的阻塞问题。
   Redis 是内存数据库，数据都在内存中，仅在改变时才会回写。但在磁盘回写的时候，由于需要拷贝内存镜像，整个处于阻塞状态，服务器不会做任何相应，在数据少的情况下阻塞时间也很少，可以忽略。但数据达到G这个级别之后的阻塞绝对是致命的。而且这个阻塞由Redis特性决定，无法彻底解决。
   通过主从这种方式对任务进行分工，主机负责写入，通过配置文件中的save选项，减少回写甚至直接取消数据回写，将数据持久化的任务交由slaver主机进行。一旦宕机，由slaver主机上的数据恢复出master。
2. 数据热迁移。
   这个很好理解了，数据迁移示意图

共享表空间方式

由于是默认的方式，就暂且理解为Mysql官方推荐的方式。相对而言所有的数据都在一个（或几个）文件中，比较利于管理，而且在操作的时候只需要open这一个（或几个）文件即可，相对来说代价很低。

但问题是在数据达到以G为单位来计算的时候优劣逆转。一个大小惊人的文件很不利于管理，而且对于一个如此巨大的文件来说，读写它需要耗费的资源一样巨大。更加令人费解的是，MySQL竟然将索引和数据保存于同一个文件中，索引和数据之间尚存在资源争用，不利于性能的提升。你当然可以通过innodb_data_file_path的配置规划多个表空间文件，但MySQL的逻辑是“用满后增加”，仅仅是一个文件的拆分而已，不能从根本上分离数据和索引。

之前曾经遭遇到700G以上的表空间文件，而且更加让人郁闷的是对于如此大的文件还在以每天数G的数量增加。由于无法停机，即便是拷贝一下也要花费差不多一夜，只能眼睁睁看着它继续增大而毫无保守可行的办法。

独立表空间方式

相对而言对立表空间每个表都有独立的多个数据文件，而且做到了索引和数据的分离。多个小文件之间很方便的完成跨数据库甚至跨硬件的数据拷贝和迁移。相对来说灵活性很好。

这样做同样带来另一个方面的问题。当数据库中的表数量达到一定级别时，每次操作所涉及的文件过多，如果按照默认Centos的ulimit -n = 1024的话，仅仅只能保证同时打开256个表以内，这在习惯上“拆库拆表”的MySQL数据结构上很难达到要求。尚且这种数据文件的利用率不算很高，当大量“不高”的文件集中起来，浪费的空间也很惊人，更何况最后可能出现的状况不是“一堆K级别的小文件”而是“一堆G级别的大文件”，有点适得其反的意思。你自然可以联想到分区表，又是一个“仅仅做文件拆分而已”，多个分区文件缺一不可。

之前同样遇到过这个问题，MySQL连接大的状况下大量的timeout，但主机负载还算可以，查了一圈才知道是open files限制的问题，限制一修改，负载变得惊人，但连接数却又提升的不多。

总之，两种方法各有所长，部分互补，但都不是解决问题的终极方案。期待MySQL能够出现真正意义上表空间的概念，更加自由的规划数据文件。

之前曾经通过nginx的memcache扩展，配合TokyoTyrant Server（每次都觉得很别嘴）这个即支持memcache协议，又可以持久化的Key-Value实现过琐碎文件的管理，但限于Memcache无法逾越的1M鸿沟，只能保存些小文件。

这些天看到一个Nginx第三方插件 HttpRedis, 本身仅仅只是计划用它来做一些短域名跳转之类的应用，忽然觉得Redis没有内容主体的限制，而且性能优良，完全可以用作琐碎文件的下载。

首先下载nginx——不知不觉nginx已经有了正式的1.0以上的版本了！

wget http://www.nginx.org/download/nginx-1.0.10.tar.gz

下载 http_redis:

wget http://people.freebsd.org/~osa/ngx_http_redis-0.3.5.tar.gz

开始编译，没什么复杂的：

tar vzxf nginx-1.0.10.tar.gz
tar vzxf  ngx_http_redis-0.3.5.tar.gz

cd nginx-1.0.10
./configure –user=www –group=www –prefix=/app/nginx  –add-module=../ngx_http_redis-0.3.5

make -j4 && make install //部分CPU无法通过编译，还是乖乖的make  && make install

修改nginx的配置文件：

在http{}之中加入：

server {

    listen       80;
    server_name  www.test.com;

    location / {
      set $redis_key CACHE_$request_uri;
      redis_pass     localhost:6379;

      default_type   text/html;
    }
}

安装redis，还是老一套：

apt-get install redis-serve
/etc/init.d/redis-server start

比如你现在需要通过http://www.test.com/a.html访问一个页面，则可以直接通过下面的方法在redis中塞入一个值，依次类推：

redis-cli
redis > set CACHE_a.html “Hello World!”
OK

redis > set CACHE_/b/a.html “Hello World!”
OK

调试无误后就可以使用程序端直接向redis中写入数据了。

当然，也可以通过设置不同的“default_type”存放图片或者其他类型的文件。 由于此扩展支持redis连接池，而且redis本身也支持master-slaver数据同步，完全可以实现redis端的负载均衡（考虑到redis的性能，我觉得意义不大，除非为了热备份）。需要注意的是Redis是内存数据库，尽管它有定时将数据回写磁盘的机制，但如果不启用vm的话，内存是一个硬性的限制。

题目：1只羊第二年后开始繁殖，每年一胎，每胎一只，直到第5年死亡，列出前十年的羊的数量。

首先照例是普青：

<?php
function foo($n, $echo = true)
{
    $i = 1;
    $a = 1;

    while($i < = $n)
    {
        $c = $b;
        $b += $a;
        $a = $c;

        if ($i > 5)
        {
            $b -= (foo($i -5, false) -1)
        }
        if ($echo)
            echo "The " . $ i ."th year: " . $b ."\n";
        i ++;
    }
}
foo(10);
?>

资质一般，仅仅是做出了题目而已，没有考虑之后代码的维护，以及层层递归造成的性能浪费

接下来是文青： 

<?php

function getSheepNumber($finalYear)
{
    if ($finalYear < 1 ) return 0;
    $thisYear = 1;
    $histoyRecord = array ('1' = 1);

    while($thisYear < = $finalYear)
    {
        $lastYear = $thisYear - 1;
        $theYearBeforLastYear = $lastYear - 1;
        if ($theYearBeforLastYear < 0 )
            $historyRecord[$thisYear] = $historyRecord[$lastYear];
        else
            $historyRecord[$thisYear] =
                $historyRecord[$lastYear] + $historyRecord[$theYearBeforLastYea];

        if ($thisYear > 5)
        {
            $theYearBefor5Years = $lastYear - 5;
            $historyRecord[$thisYear] -= $historyRecord[$theYearBefor5Years];
        }
        $thisYear ++;
    }
    return $historyRecord[$thisYear]
}

for ($year = 1; $year<=10; $year++)
{
    switch ($year)
    {
        case 1:
            echo "The 1st year: ";
            break;
        case 2:
            echo "The 2nd year: ";
            break;
        case 3:
            echo "The 3rd year: ";
            break;
        default:
            echo "The " . $year ."th year: ";
            break;
    }

    $sheepCount = getSheepNumber($year);
    echo $sheepCount . "\n";
}
?>

足够优雅，也有了不错的优化。可惜为了这优雅，循环调用，导致尽管优化了性能但依旧有潜力可挖，而且代码也罗嗦的可以了。谁让文青都不食人间烟火呢？

接下来2B青闪亮登场：

<?php
function foo($n)
{
    $year_2 = $year_1 = 1;
    $loop = 2;

    while( $n > 0 )
    {
        $last_year = "year_" . $loop;
        $last_2_year = "year_" . ($loop - 1);
        $loop ++;

        $this_year = "year_" . $loop;

        $$this_year = $$last_2_year + $$last_year;

        if ($loop > 5)
            $$this_year -= ${substr($this_year, 0 , -2) . ($loop - 5)};
?>
            The <?php =$loop ?>th year <?php =$$this_year ?>
<?php
    }
}
foo(10);
?>

好吧，我不得不承认PHP的特性真的很方便。为了特性而特性这就是2B。

NB青的,颇有爱尔兰(Erlang)风格：

<?php

function sheepBorn($n, &$list)
{
    if ($list[$n]) return $list[$n];

    if $n < 1   return 0;
    if $n <= 2  return 1;

    $list[$n] = sheepBorn( $n - 1, $list ) + sheepBorn( $n - 2,  $list ) - sheepBorn( $n - 5,  $list );
    return $list[$n];
}

$list = array();
for ($year = 1; $year<=10; $year++)
    echo "The " . $year ."th year: " . sheepBorn($year, $list) . "\n" ;
?>

够强！可这样的代码，除了表达一下自己的超强算法之外，给别人带来的困惑也会增加，要在注释上多下功夫了。

最终，真相帝降临：

<?php
for($i = 0; $i <= 10; $i ++)
{
    if ($i < 5)
        echo "The " . $i . "year is: 1 ";
    else
        echo "The " . $i . "year is: 0 ";
}

只有一只羊的情况下确实不能繁殖。

由于项目本身是PHP的初次看到这个项目，首先想到的是Apache + mod_php的方式，配合php的ob_start()方式直接调用，就如同我之前的一篇东西所说的那样。可问题不这么简单：

1. 系统是nginx + php-fpm方式，php-fpm“hold不住”过多的Http请求，而nginx需要调整响应时间。
2. 用户数量很多，Apache的消耗很大。本身功能点很小，实现成本不合算。

说到并发，Apache采用的方式是大量的fork进程，通过“人多力量大”的方式应对多个请求，这样的基于进程（线程）模型的并发，一旦调用sleep，进程只是休眠而已，仍然占用着内存，仍然需要进程调度，资源始终得不到释放，资源自然无法得到控制。这些年nginx的流行大多都是因为nginx采用的epoll方式有效的解决这个问题——直接挂掉进程，然后再指定时间内重新启用。这就是传说中的“非阻塞”(asynchronous IO  AIO)。

多并发、轻量级应用，我首先想到的是Python，加上“非阻塞”关键字，得到的结果就是Tornado。

tornado原本是FriendFeed引擎的开源版本，本身就是为解决“C10K”问题而生的。

稍微研究了一下，coding也很简便：

#!/usr/bin/env python
#By Litrin J
#http://www.litrin.net/
import tornado.httpserver
import tornado.ioloop
import tornado.options
import tornado.web
import time, redis, hashlib,random
from tornado.options import define, options

define("port", default=8888, help="run on the given port", type=int)

class LongPolling(tornado.web.RequestHandler):

    minWaitTime = 15
    maxWaitTime = 900

    RedisHost   = "172.18.194.98"
    RedisPrefix = "Q/MSG%s"

    SignSalt    = "salt"

    StopCode    = "{'stop':1}"

    @tornado.web.asynchronous
    def get(self):
        sUid        = self.get_argument("uid", None)
        sSign       = self.get_argument("sign", None)
        sJsonCall   = self.get_argument("jsonCallback", None)

        if (sUid is None or sSign is None
                or self.checkSign(sUid, sSign) == False):
            raise tornado.web.HTTPError(404)
            self.clear()

        else:
            self.doLongPolling(callback=self.onWaitting)

    def checkSign(self, sUid, sSign):
        return True

    def doLongPolling(self, callback):
        #Check if the client close the connection
        if self.request.connection.stream.closed():
            self.clear()

        sKey        =   self.RedisPrefix % self.uid
        res         =   redis.Redis(self.RedisHost)
        sMessage    =   res.rpop(sKey)
        del res #close the redis at 1st time

        callback(sMessage)

    def onWaitting(self, sMessage):
        if (sMessage is not None):
            self.onRespones(sMessage)
        else:
            iNextPollingTime = time.time() + self.minWaitTime
            if self.minWaitTime < self.maxWaitTime:
                self.minWaitTime *= 2
                #Can't useing time.sleep for no-bloking mode
                tornado.ioloop.IOLoop.instance().add_timeout(
                iNextPollingTime ,
                lambda: self.doLongPolling(callback=self.onWaitting)
            )
            else:
                self.onRespones(self.StopCode)

    def onRespones(self, sMessage):
        sJsonCall   = self.get_argument("jsonCallback", None)
        if sJsonCall is not None:
            sMessage= sJsonCall + "( " + sMessage.decode('utf-8') + ")"

        self.write(sMessage)
        self.finish()

def main():
    tornado.options.parse_command_line()
    application = tornado.web.Application([
        (r"/", LongPolling),
    ])
    http_server = tornado.httpserver.HTTPServer(application)
    http_server.listen(options.port)
    tornado.ioloop.IOLoop.instance().start()

if __name__ == "__main__":
    main()

一旦建立http连接，系统会每隔一段时间去轮询用户的队列中是否有数据，有数据时才向客户端发送请求，否则就是“长时间小菊花”状态。很简单，仅仅用了不到100行代码的样子。当然，为了安全因素和节省资源，代码里添加了很多限制性的操作，否则可能会更简洁高效。

需要注意的是，tornado的理念就是建立在“非阻塞”基础上的，你当然可以选择time.sleep(n)，但传统上的time.sleep(n)方式的休眠会导致IO阻塞，故只能采用tornado.ioloop.IOLoop.instance().add_timeout 的方法回调来回调去，将下次启动的时间转给系统。话说回来，这是我第一次在Java或JS以外使用回调函数……

初步测试了一下，借助Redis本身就很强的并发能力在台式机上可以每秒钟完成4K次请求以上，并可以保持同时4K以上的访问不掉线，此时的CPU load仍然保持在1以下，单是测试的结果就足以让Apache+Php组合汗颜。

部署的时候采用了单IP多端口方式，服务器有4个核心，决定开4个端口对应，分别是8885~8888，修改

define("port", default=8888, help="run on the given port", type=int)

即可

前端nginx用负责负载分发：

upstream backend {
        server 127.0.0.1:8888;
        server 127.0.0.1:8887;
        server 127.0.0.1:8886;
        server 127.0.0.1:8885;
}
 server{
        listen  80;
        server_name message.test.com;
        keepalive_timeout 65;    #
        proxy_read_timeout 2000; #
        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;

    location / {
        proxy_pass_header Server;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Scheme $scheme;

        proxy_pass  http://backend;
        }
}

需要注意的是，这样的httpSocket方式很可能被内核认为是SYN攻击，而且对于大量的keep alive而言，很可能超过核心限制，还要修改sysctl参数。

#系统最大打开文件数
fs.file-max = 201510

#TCP连接的最长时间
net.ipv4.tcp_keepalive_time = 1800
#出现问题的尝试次数
net.ipv4.tcp_keepalive_probes = 15
#检查是否连接的等待时间
net.ipv4.tcp_keepalive_intvl = 60
#不进行SYN cookies防御
net.ipv4.tcp_syncookies = 0

在桌面版本的Linux中，一般默认已经安装了调速器的控制台，并可以通过类似gnome控制栏插件的方式简单的启用和调整。对于Server版本，由于定位不同，这样的设置意义不大，但可以手工安装。考虑到要做“绿色IT”，个人觉得在一定范围内适当的使用不但不会影响性能，而且还可以降低主机温度，达到延长主机寿命的功效。具体方法如下：

sudo apt-get install cpufrequtils

手工调整CPU频率，需要CPU支持，虽然现如今大多数CPU都支持类似的技术（Speed Step之Intel和nCool之AMD），但恰巧我有一台ATOM芯片的机器就不支持。同样需要注意的是，不是超频，而是降频，指望这种方法为CPU超频的话我劝您还是直接去 BIOS里跳吧

cpufreq-selector -f  频率数，单位是kHz
cpufreq-set -d 最高频率
cpufreq-set -u 最低频率

查看CPU状态，不需要太多解释了吧

cpufreq-info

设置CPU运行模式，这才是主要的。系统默认会为CPU设置几种模式方便直接切换

cpufreq-set -g 模式类型

模式类型

• powersave，省电模式，简洁明了，就是最省电的状态，CPU始终工作在最低频率上。
• userspace，用户定制，手工定制频率的方式。
• ondemand，守护模式，自动根据系统负载调整模式，负载越高，频率越高。这是绝大多数系统选择的模式。
• conservative，保守模式，有些类似于ondemand，但不同于ondemand一有负载就提高频率到最高，次模式尽量采用较低的模式，直至满载无法承受才提升频率。
• performance，性能模式，系统始终工作在最高频率之上。

说起终端的类型，尽管现在的终端大多都是一个PC而已，事实上在N多年前，终端类型可能仅仅只是体现了厂商的品牌而已，不同的终端类型多如牛毛。他们对于光标、控制字符以及颜色的定义相互都不兼容，历史遗留的问题了。包括之前也发觉很多主机商“backspace”键无效，必须使用ctrl+h进行退格的问题。

在Mac的终端下操作：

LitrindeMacBook-Pro:~ litrin$ echo $TERM
vt100

LitrindeMacBook-Pro:~ litrin$ infocmp vt100
#	Reconstructed via infocmp from file: /usr/share/terminfo/76/vt100
vt100|vt100-am|dec vt100 (w/advanced video),
	am, mc5i, msgr, xenl, xon,
	cols#80, it#8, lines#24, vt#3,
	acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
	bel=^G, blink=\E[5m$<2>, bold=\E[1m$<2>,
	clear=\E[H\E[J$<50>, cr=^M, csr=\E[%i%p1%d;%p2%dr,
	cub=\E[%p1%dD, cub1=^H, cud=\E[%p1%dB, cud1=^J,
	cuf=\E[%p1%dC, cuf1=\E[C$<2>,
	cup=\E[%i%p1%d;%p2%dH$<5>, cuu=\E[%p1%dA,
	cuu1=\E[A$<2>, ed=\E[J$<50>, el=\E[K$<3>, el1=\E[1K$<3>,
	enacs=\E(B\E)0, home=\E[H, ht=^I, hts=\EH, ind=^J, ka1=\EOq,
	ka3=\EOs, kb2=\EOr, kbs=^H, kc1=\EOp, kc3=\EOn, kcub1=\EOD,
	kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kent=\EOM, kf0=\EOy,
	kf1=\EOP, kf10=\EOx, kf2=\EOQ, kf3=\EOR, kf4=\EOS, kf5=\EOt,
	kf6=\EOu, kf7=\EOv, kf8=\EOl, kf9=\EOw, lf1=pf1, lf2=pf2,
	lf3=pf3, lf4=pf4, mc0=\E[0i, mc4=\E[4i, mc5=\E[5i, rc=\E8,
	rev=\E[7m$<2>, ri=\EM$<5>, rmacs=^O, rmam=\E[?7l,
	rmkx=\E[?1l\E>, rmso=\E[m$<2>, rmul=\E[m$<2>,
	rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, sc=\E7,
	sgr=\E[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;m%?%p9%t\016%e\017%;$<2>,
	sgr0=\E[m\017$<2>, smacs=^N, smam=\E[?7h, smkx=\E[?1h\E=,
	smso=\E[7m$<2>, smul=\E[4m$<2>, tbc=\E[3g,

说明了主机的默认终端类型正是导致出现问题的“xterm-256color”，对于每一种终端的定义，需要在terminfo文件中定义，Mac下这个文件保存在/usr/share/terminfo/目录下，而这个故障出现的最终原因是Ubuntu或者说Debian系的Linux默认没有xterm-256color终端的定义，而Lion操作系统升级之后，默认的终端类型从之前的vt100变成了xterm-color。

扯了这么多，解决方案有两种，都很简单：

1. 让server端支持xterm-256color：apt-get install ncurses-term，安装终端支持。
2. 在Mac下终端的“偏好设置”，“设置”选项卡，“高级”选项，“声明终端为：”修改为“xterm-color”或者其他的类型，看个人喜好了。

个人推荐还是采用方法2解决，此外，你也可以通过定义其他类型的终端，解决其他类似的问题。

2011－10－05（PST）来自：乔布斯的MacBook Pro

默认的Linux发行版中的内核配置都会开启tmpfs，映射到了/dev/下的shm目录。可以通过df 命令查看结果如下：

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             146G   14G  125G  10% /
varrun                501M   84K  501M   1% /var/run
varlock               501M     0  501M   0% /var/lock
udev                  501M   32K  501M   1% /dev
devshm                501M     0  501M   0% /dev/shm

默认配置的shm分区正好是内存的一半。

可以重新调整大小：

vi /etc/fstab
tmpfs /dev/shm tmpfs defaults,size=4096M 0 0

umount /dev/shm; mount /dev/shm

不同于文件系统/dev/shm不是一个文件，是一个目录，完全可以通过文件链接的方式挂装到指定目录，还是推荐采用mount方式：

mount –bind /dev/shm /data

既然仅仅只是当作一个容器，从性能上考虑那为什么要用MySQL呢？

最近在研究一些NoSQL的东西，memcache类这类的纯Key-value；redis这类key-list；以及更加接近于关系型的MongoDB。这类的数据容器相较MySQL这类SQL数据库而言，更多的都是在性能上做大幅提升。从搜索能力上讲，MySQL的搜索能力又远不及Sphinx或者Solr这类单纯的索引服务器。如果说关系型数据库的优势在于一致性。那事物操作本身也不是MySQL所擅长的，“拆库拆表”的设计理念更是打破了一致性的优势。MySQL剩下的优势恐怕只剩下了“便于维护”这一条了吧。

mysql mongodb 写入对比

mysql mongodb 查询对比

mysql mongodb 资源对比

相比MySQL这些年做的改进，几乎都是在完善事物处理这类高级的SQL逻辑。之前人们选择MySQL的原因，其实很少是由于MySQL的事务处理，而是性能方面的优势。当MySQL不再将性能的提升作为首要任务时，加上近一段时间风声水起的SNS热潮，MySQL的王者地位已经逐渐被NoSQL数据库挑战——甚至出现了完全排除MySQL的SNS框架。

据说MySQL5.6中启用了对于Memcache的支持，看来连MySQL自己也顿悟了……

*nix成员名单：

• Solaris 10 授权包，for sparc and x86
• Solaris 9 安装包，for sparc
• Ubuntu 606， for x86, x86_64, power mac
• Ubuntu 804，for x86, x86_64
• Ubuntu 904，for x86
• Suse Linux 10.2
• Fedora 5 for x86_64

fork，顾名思义就是一把叉子，或者专业一点叫做复制叉。作为sys/type.h的一个函数，系统在每次调用fork()之后，将会以此为分叉，对进程本身进行复制，新的进程和旧进程有近乎完全一致的cpu时间和内存寄存器。

这本身并不重要，重要的是对于fork()函数的返回而言，父进程返回的是子进程的pid，而子进程返回的是0，当然还有一个-1的返回表示fork()的失败。对与C大致如此：

#include <unistd.h>;
#include <sys/types.h>;

main ()
{
        pid_t pid;
        pid=fork();

        if (pid < 0)
                printf("error in fork!");
        else
        {
			if (pid == 0)
                        {
                                 printf("i am the child process, my process id is %d\n",getpid());
		                 exit();
                        }
			else
                        {
                                printf("i am the parent process, my process id is %d\n",getpid());
				exit();
                         }
         }
}

执行后，父进程和子进程分别将自己的Pid打印出来。

既然如此，对于我常用的php来说，可以同样做到后端执刑一些耗时的操作，从而达到异步的效果：

function mulitProcess()/*{{{*/
{
        if (function_exists(pcntl_fork))
        {
            $pid = pcntl_fork();

		    if ( $pid === -1 )
		    {
		    	return false;
		    }
		    elseif ( $pid )
		    {
                        usleep(10);
                        exit();
                    }
                    else
                    {
                         doBackground();
                    }
        }
        // windows system or php not support PCNTL libs
        else
        {
			doBackground();
        }
}

对于很多守护进程来说，脱离shell（即“脱壳”）正是利用了这种方式进行进程复制。对与PHP来说需要进行2次fork之后配合一个死循环即可,当然为了防止死循环真的“死掉”需要sleep()函数来进行休眠：

function daemonize() /*{{{*/
{
    $pid    =   pcntl_fork();

    if (-1 == $pid)
    {
        return false;
    }
    elseif ($pid)  //parent process
    {
        usleep(500);
        exit();
    }
    $sid    =   posix_setsid();

    if (!$sid)
    {
        return false;
    }

    $pid    =   pcntl_fork();

    if ( -1 == $pid )
    {
        return false;
    }
    elseif ($pid)
    {
        usleep(500);
        exit(0);
    }

    // deny process display and io
    if (defined('STDIN'))
            fclose(STDIN);

    if (defined('STDOUT'))
            fclose(STDOUT);

    if (defined('STDERR'))
            fclose(STDERR);
    while(true)
            doSomeThing();

}/*}}}*/

需要注意的是，windows没有fork()，php直接屏蔽了PCNL函数库，而python相对没有一棒子打死。Python采用的方式等于在命令行重新调用一次脚本，如果直接将没有考虑到这个问题的python脚本直接移植windows的话进程数量将会爆炸式增长，很快就会导致资源耗尽。由于我在windows上大多只是进行测试而已，多进程带来的性能优势不重要，习惯上我的方法就是使用threading模块替换掉mulitprocessing模块。写个示例：

try: #if os.name == 'posix':
    from multiprocessing import Process, Queue
except: #else:
    from threading import Thread as Process
    from Queue import Queue

要说最近最热的云计算，不得不提Hadoop。这个项目就是为集群运算而生的。依赖于它的项目n多，个人感觉hadoop已经逐渐成为一个“基于Java的分布式运算中间件”。

这里安装的hadoop为ver 0.21.0版本，包含了HDFS分布式文件系统。平台为老一套的Ubuntu 1104 server for amd64。

既然是Java Base的，首先要准备jdk环境。默认1104已经把java从apt中剔除了——跟oracle收购sun不无关系，尽管openjdk还在，我还是建议安装sun-jdk。具体实现如下：

echo “deb http://archive.canonical.com/ natty partner” >> /etc/apt/sources.list #添加源
apt-get update
apt-get install sun-java-jdk

文件多而大，耐心等待。

基础环境

默认apt方式安装的jdk目录为/usr/lib/jvm/java-6-sun ，等待jdk完成之后，

echo "/usr/lib/jvm/java-6-sun"  > /etc/jvm

官方建议关闭ipv6，尽管我不清楚有什么影响

echo "blacklist ipv6" >> /etc/modprobe.d/blacklist

建立用户/组，没什么要解释的

addgroup hadoop
adduser --ingroup hadoop hadoop

修改环境变量，vi /etc/bash.bashrc，在末尾添加：

export JAVA_HOME=/usr/lib/jvm/java-6-sun
export JDK_HOME=$JAVA_HOME
export PATH=$PATH:$JAVA_HOME/bin

切换用户到hadoop, su – hadoop

调通ssh，具体参见这里之前的东西。

mkdir .ssh
cd .ssh
ssh-keygen -t rsa
cat id_rsa.pub >> authorized_keys
ssh localhost

配置Hadoop

我默认已经使用hadoop用户进行操作，root权限可以不用了。

将下载后的hadoop保存在适当的目录下，我选择了/opt/hadoop目录。

修改/opt/hadoop/conf/hadoop-env.sh文件中，添加 export JAVA_HOME=/usr/lib/jvm/java-6-sun

cd /opt/hadoop/conf 一堆的配置文件要改。

conf/core-site.xml:

<configuration>
     <property>
         <name>fs.default.name</name><!--文件系统名称-->
        <!--<value>hdfs://localhost:9000</value>单机，不使用集群文件系统 --><value>/date/hadoop</value>
     </property>
</configuration>

conf/hdfs-site.xml:

<configuration>
     <property>
         <name>dfs.replication</name>
         <value>1</value>
     </property>
</configuration>

conf/mapred-site.xml:

<configuration>
     <property>
         <name>mapred.job.tracker</name>
         <value>localhost:9001</value>
     </property>
</configuration>

需要注意的是，不同的版本号之间，配置方式有细微的不同。

配置OK!

Linux www 3.0.13.0.1 #2 SMP Wed Aug 17 16:05:25 CST 2011 x86_64 x86_64 x86_64 GNU/Linux

作为debian系的Ubuntu，相对制作kernel包还是比较容易的。

wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.2.tar.bz2

apt-get install build-essential kernel-package

tar vzxf  linux-3.0.2.tar.bz2

cd linux-3.0.2

make menuconfig

make-kpkg –initrd  kernel_image kernel-headers

漫长的编译之后上层目录会出现 linux-headers-* 和linux-image-*连个包，直接dpkg -i 就OK了，很方便。

话说回来，这次2->3的升级有点不知所云，没有什么较大的新特性的引入，仅仅是Linus大神认为的2.6.39的版本号太大了。也不知道今后linux是否还延续“单数不稳定的传统”。相比2.2->2.4, 2.4->2.6的跨越，反而成了讽刺。

“开源小站”最初是基于drupal构建，基础数据库是postgresql。后来由于drupal的性能问题以及框死了的postgresql，只能整体迁移到了wordpress+mysql。当然迁移好之后，考虑到drupal和wordpress的链接地址的不同，修改了wordpress的部分代码，让之前的外链不至于失效。后来索性就通过apache的mod_rewrite模块添加了301跳转，wordpress的版本也可以随着“持续演进”了。

由于wordpress或者这一类的CMS系统本身不是一个性能优化的产品，后来一段时间搬迁过一次，平台是vps的虚拟机。性能问题很突出，首页打开竟然需要2.7秒以上，加上传输耗时，超出了3秒的范围，严重影响用户体验。于是不得不在wordpress的代码上进行修改。页面全部缓存到了memcache。响应时间减少到1.5秒以下，基本可以满足大部分需求。但这样就无法跟随wordpress持续演进了。wp的版本只能定死在了某个版本号上。考虑到安全因素，我只能说，这是3.1之前的“某个版本”。

关于硬件环境，最初的drupal版本是一台相对很“牛”的机器，双核志强*2 + 4G RAM+ RAID5。所以当初提供了很多开源系统镜像下载。系统的瓶颈出现在网络带宽上，可谓“衣食无忧”。

之后的变故，加上域名备案的因素，使得网站一度只能跑在一台win2003的virtual server上，内存只有64M，从一个极端到了另一个极端。之后很长一段时间，开源小站始终运行在虚拟机或者vps之上。当然，由此带来的流量下滑不是一点点，但访客停留时间大大增加。也算抹平了。

后来，设法弄到了一点资源，与别人合用了一台主机，4核Xeon+4GRAM + RAID1，磁盘总是不够用，甚至为此都不保存访问日志。

后来，曾经狂热的支持了一把atom，于是自己用atom的平台搭建了一台服务器，1u高度标准机箱，atom-230,1.6G +2GRAM+160G的笔记本硬盘，操作系统选择了Ubuntu的804 Server，竟然跑得很流畅，这就是现在开源小站的主机。当然，也感谢某位朋友，免费提供了他们所代理的某款网络安全产品，用以作为我们小站的前端防火墙。在前端防火墙之后，通过端口映射的方式完成了网站80端口的指向。负担一部分iptable的任务，同时也作为SSH和远程重起主机的跳板。

之后，加入了xml-rpc服务，同时将文章推送到几个免费博客和litrinjiang.appspot.com，尽管格式全乱，但至少也算是备份吧。