System

以前在cu上的blog，虽然整体写的比较乱。不过也算是自己以前折腾了好久写的，准备慢慢迁移过来。。

很久很久以前，nginx的upstream还不支持HTTP 1.1的时候，nginx做反响代理时只能使用短链接。设想以下的结构中CLient–http 1.1 keepalive —>Nginx(proxy)—http 1.1 connection: close–>APP 经常会看到后端APP上有大量的TIME_WAIT状态的链接。这几天又重新读了一下TCP详解和UNP。状态变迁图如下 根据上图如果是客户端先发FIN包主动关闭，服务端其实是不会进入TIME_WAIT状态的 如果是客户端和服务端同时关闭的话，客户端和服务端都会出现TIME_WAIT的状态 apache设置keepalive Off的时候每次都会主动关闭掉，所以TIME_wait的数量非常多。 主要不是客户端完全主动关闭，那么服务端都是会出现这个TIME_WAIT的。 针对apache的keepalive on和off都单独抓包了。 On Off 以上2图中的客户端都是10.253.85.156可以清楚的看到当时keepalive设置为on的时候都是客户端先发FIN包，而设置为Off的时候都是服务器端先发FIN包去关闭。 在TCP/IP详解第三卷其实也有说明 今天又发现线上的机器有很多CLOSE_WAIT状态的链接，接近1W个。。又反复看了下TCP/IP详解的内容。基本定位为本地发起链接去连接远程的8080端口， 远程的服务端在完成了一个调用后主动发起链接关闭发了一个FIN包给本地服务器，然后就没有下文了，就产生了CLOSE_WAIT。。正常情况下本地服务器需要回一个ACK后再向对远程服务器发一个FIN包，再等到对方回复ACK后才能CLOSE。为了证实我的猜测我也到这里的“远程服务器“去查看了一下，发现很多链接处于FIN_WAIT2的状态。对于FIN_WAIT2的链接默认会在60s后进行回收，加入特别多的话可以降低tcp_fin_timeout。其实产生CLOSE_WAIT的原因也就是自己没有去调用close来关闭连接。比如connfd = accept(listenfd,xxx,xx)后对这个connfd进行操作完就直接不管了，而对方在完成操作后自己调用了close关闭了链接，这个时候自己就一直处于CLOSE_WAIT的状态，网上有很多说法说这个状态2小时后会被回收，但是实际测试linux根本不会回收的。叔度的这个blog也提到了类似的问题，这种情况基本都是软件有bug。。 [blog](http://blog.zhuzhaoyuan.com/2009/03/a-word-on-time_wait-and-close_wait/)

今天主要是还原一个线上的问题，自己搞了几个机器配置了一下nginx模拟做代理时后端服务器速度跟不上的问题。基本的结构如下 client —->nginx(proxy)—nginx server(limit rps 400/s) 因为我总的就3个机器，所以后端的nginx server里面配置的是 limit_conn_zone $binary_remote_addr zone=connzone:10m; limit_req_zone $binary_remote_addr zone=reqzone:10m rate=400r/s; server {listen 1081; server_name localhost; keepalive_requests 1000; 简单的对比测试了一下后端限速和不限速的情况。当后端不限速的时候压测时代理proxy 的load非常高，单个核的机器CPU使用率能到100%,usr，sys，soft各占了30%左右，但是后端服务器的load比较低，只有20%左右。当后端机器限速的时候proxy上会出现大量的503,并且load还是很高，基本和前面的相同，但是后端的服务器load也会比较高，在30%–80%间波动。检查后端服务器的日志可以发现很多健康检测的请求被置为了503，也就是存在服务器被踢掉的情况。 另外顺便测试了一下apache的配置，之前的woker的配置``` Timeout 180KeepAlive OnMaxKeepAliveRequests 100KeepAliveTimeout 360 StartServers 10ServerLimit 50MaxClients 1500MinSpareThreads 50MaxSpareThreads 200ThreadsPerChild 50MaxRequestsPerChild 10000

因为DB120的无线速度确实比较慢，所以本来是打算买个FW300R V2或者TP-link 841n v[3-7]来刷OpenWrt的。结果后来在淘宝上找到了比较便宜的740n V4，算上电源才39块钱一个。就直接拍了一个。740n的ar7240的频率被限制在350Mhz，所以就采用了曲线刷机的方式，然后恰好我下的带改了400Mhz的uboot的740n的固件头校验不过，然后恰好里面带的一个dd-wrt的固件是能直接刷的。所以就740n –> dd-wrt –>741n –>741n(400Mhz uboot)–>OpenWrtdd-wrt下刷741n的估固件这样做然后就dd-wrt刷会下的固件，cat /proc/mtd确认分区名称mtd -r write 741.bin linux 具体的过程不细说了，需要用到的中转固件是这里下的。 [这里](http://115.com/file/e604qo9u)

公司发的3G卡有大半年没有用过了，主要是平时很少外出。今天测试了一下再debian下进行拨号配置，其实还是比较简单的。主要参考了网上现有的文章。 只需要安装 wvdial, usb-modeswitch就可以了。然后进行一下简单的配置，以下是我使用的配置文件# cat wvdial.conf[Dialer Defaults]Init = AT+CGDCONT=1,”IP”,”uninet”Init1 = ATZInit2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0Init6 = AT+CFUN =1Modem Type = Analog ModemBaud = 115200New PPPD = yesModem = /dev/ttyUSB2ISDN = 0Phone = *99#Username = anyAuto DNS = 0Password = anyNew PPPD = yesIdle Seconds = 300Stupid Mode = 1 [文章](http://hi.baidu.com/pcdigger/item/4ad5b2209b7ebc142a0f1c52) 其实每一项的含义都可以man wvdial.conf查看的，比如Stupid Mode就是 Stupid ModeWhen wvdial is in Stupid Mode, it does not attempt to interpret any prompts from the terminal server.It starts pppd immediately after the modem connects. Apparently there are ISP’s that actually give youa login prompt, but work only if you start PPP, rather than logging in. Go figure. Stupid Mode is(naturally) disabled by default.之前我没有添加这个配置，启动wvdial后就会处于等待的状态，配置这个选项后启动就立即进行拨号了。

cpanm支持安装模块的时候临时直接制定一个路径，对于没有root权限的人来说是比较方面的。curl -LO http://bit.ly/cpanmchmox +x cpanmcp cpanm /usr/sbin 然后直接cpanm http://mirrors.163.com/cpan/authors/id/S/SA/SALVA/Net-OpenSSH-0.58_04.tar.gz ～/cpanlib/就OK了。 但是在写脚本的时候要在BEGIN阶段把这个目录添加到@INC里。类似：BEGIN { unshift @INC, ‘/home/pm/cpanlib/lib/perl5/’ } 这样就可以直接先用自己安装的新版本的模块，而不是用系统里带的老版本的模块了。

因为想使用Net:OpenSSH的时候能forward_agent，就测试了一下最新版本的Net::OpenSSH.结果比较杯具的是发现forward_agent参数指定后不顶用。仔细看了一下模块的代码，作者貌似是犯了一个比较低级的错误。有2处是if ($self->{_forward_agent}) {my $forward_agent = delete $opts{forward_agent};push @ssh_opts, ($forward_agent ? ‘-A’ : ‘-a’) if defined $forward_agent;}这里实际是如果输入的时候定义了forward_agent就给ssh_opts加一个-A，表示开启转发。但是作者却还是从$opts{forward_agent}里面取。实际上第一次这样取值后，这个就被delete掉了。我直接改了一下代码，patch如下pm@debian:~$ cat OpenSSH.diff1160,1162c1160,1161< if ($self->{_forward_agent}) {< my $forward_agent = delete $opts{forward_agent}; < push @ssh_opts, ($forward_agent ? '-A' : '-a') if defined $forward_agent; --- > if (defined $self->{_forward_agent}) {> push @ssh_opts, ($self->{_forward_agent} ? ‘-A’ : ‘-a’); 1294,1296c1293,1294< if ($self->{_forward_agent}) {< my $forward_agent = delete $opts{forward_agent}; < push @ssh_opts, ($forward_agent ? '-A' : '-a') if defined $forward_agent; --- > if (defined $self->{_forward_agent}) {> push @ssh_opts, ($self->{_forward_agent} ? ‘-A’ : ‘-a’); 修改后终于OK了。 ================UPDATE：和模块的作者联系过，模块没有bug，只是使用的时候需要直接传入参数 my $out=$ssh->capture({“forward_agent” => 1},$cmd);

最近有老的机房下线了，为了提高日志备份的速度，我就把每个应用下的日志目录整体打包压缩了。但是这样又带来了一个新的问题，那就是经常会有人来找我提取日志查看，我地根据每个人的需求把日志解压出来。因为日志存在一个存储上面，直接全部解压的话实际上会有很大的网络流量(log.tgz)NAS–>unzip server –>NAS(log)。所以就写了个脚本只把每个应用下的指定日志解压出来```bash #!/bin/bash ###############################Author: GNUer############################# LOGDIR=/mnt/abcvm/abcvm/appAPP=$1LOGNAME="$2" APPLOG=$LOGDIR/$APP/usage(){echo -e “usage:\n"echo -e “\t$0 APP LOGNAME"exit 0} OLDDIR=$(pwd)echo “unzip $APP $LOGNAME*“getlogname(){local applocal lognameapp=$1logname=$2[ ! $app ] && exit 2 for tgz in $(fi nd $LOGDIR/$APP -name “*.tgz”)do }[ $# -ne 2 ] && usagegetlogname $APP $LOGNAME

因为facebook使用bt分发应用包提高部署的速度，所以大家都在想能不能只用用现有开发成熟的软件做一个类似的方案出来。自己简单地测试了一下，凑合可以用。不过bt的客户端很难找到一个合适的，transmission本来还不错的，但是细节的使用还是需要多搞一下。昨天简单地用opentracker和ctorrent来测试了一下，基本能跑起来。 1.先设置单个的tracker服务器直接找了一个开源的tracker服务器 http://erdgeist.org/arts/software/opentracker/。对照里面的readme就可以完成安装, cvs -d :pserver:[email protected]:/cvs -z9 co libowfatcd libowfatmakecd ..cvs -d:pserver:[email protected]:/home/cvsroot co opentrackercd opentrackermake我是把opentracker安装到了/opt目录下面。然后直接用命令启动 就行了 2.使用mktorrent创建torrent(ctorrent其实也能建立种子但是测试了一下不支持目录) 根据单个文件制作种子的时候最好写绝对路径，简单测试一下把centos的一个镜像(CentOS-6.3-x86_64-LiveCD.iso )添加到种子里面。$ mktorrent -a http://xxx.test1.net:6969/announce -o centos.torrent /home/admin/CentOS-6.3-x86_64-LiveCD.isomktorrent 1.0 (c) 2007, 2009 Emil Renner Berthing 在做种的服务器上直接提交种子ctorrent centos.torrent文件校验完成后就开始做种。 3.把种子文件拷贝到需要传输的几个机器上，然后在每台服务器上运行ctorrent centos.torrent -s p2p/centos.iso就会把文件下载到p2p目录下，并把文件存为centos.iso简单测试了一下，把一个服务器上的文件删除后，可以看到另外一个服务器的在做种了，第一次上传了349M，第二次430M，还可以。局域网这样传输的速度非常的快。Listening on 0.0.0.0:2705\ 2/0/3 [2751/2768/2768] 688MB,0MB | 88078,0K/s | 81920,0K E:0,1Download complete.Total time used: 0 minutes.Seed for other 72 hours. \ 0/0/3 [2768/2768/2768] 692MB,349MB | 0,0K/s | 0,0K E:0,2/ 0/0/3 [2768/2768/2768] 692MB,779MB | 0,0K/s | 0,0K E:0,2 后续： 这个只是简单测试了部署局域网内BT P2P分发的可行性，实际上很多细节的地方需要考虑。比如tracker服务器的精细化、集群化配置，opentracker感觉还是非常粗糙的一个东西，可以设置的地方很少，而且也没有后台页面查看。另外ctorrent虽然简单用用还行，但是几千台服务器还是要客户端能后台执行，命令行远程进行种子的添加(或者自动添加某个目录下的种子)、删除、任务完成后进行通知。transmission目前看来还可以，但是在N个版本的OS上安装就比较麻烦。 ...

晚上闲着不想做其他的就测试了一下mfs，觉得还是比较简单的。主要就是把master服务器安装好，然后安装metalog服务器再安装chunkserver服务器。简单地记录了一下。需要安装fuse-libs.x86_64 fuse-devel.x86_64 fuse.x86_64(注意挂载机器上要加载fuse模块)从http://pro.hit.gemius.pl/hitredir/id=p4CVHPOzkVa0JJIK.m0Ee6dyHZEgoQb1KaiPmVK29EX.M7/url=moosefs.org/tl_files/mfscode/mfs-1.6.26.tar.gz直接搞了6个测试机器来装，在一台编译好后直接拷贝到另外几个机器上去了。1.master配置基本不需要修改，主要是根据配置文件的范例看看有没有需要改的。mfsexports.cfg根据自己的需求来改10.xx.xx.0/24 / rw,mapall=admin:admin,password=test,maxtrashtime=2m#设置2分钟回收被删除的文件空间 然后把$DIR/var/mfs下的 metadata.mfs.empty复制一份为 metadata.mfs就可以启动了。chown admin:admin /opt/mfs/var/mfs/opt/mfs/sbin/mfsmaster start2.metalog的配置cp mfsmetalogger.cfg.dist mfsmetalogger.cfg然后修改master的hostMASTER_HOST = 10.xx.xx.xx启动metalog服务/opt/mfs/sbin/mfsmetalogger start 4.客户端挂载[test6] /opt/mfs/bin/mfsmount /home/admin/testmfs -H 10.253.85.205 -p/opt/mfs/bin/mfsmount -m /home/admin/meta/ -H 10.253.85.205 -p输入密码即可 速度测试$ dd if=/dev/zero of=testmfs/bigfile count=1024 bs=10240001024+0 records in1024+0 records out1048576000 bytes (1.0 GB) copied, 11.3596 seconds, 92.3 MB/s本地磁盘测试 $ dd if=/dev/zero of=bigfile count=1024 bs=10240001024+0 records in1024+0 records out1048576000 bytes (1.0 GB) copied, 4.5809 seconds, 229 MB/s 测试在客户端上进行删除后文件实际上没有被删除掉。 设置每个目录的份数： ```bash /opt/mfs/bin/mfssetgoal -r 1 /home/admin/testmfs/test1 ```bash $ /opt/mfs/bin/mfsgetgoal -r /home/admin/testmfs/test2/home/admin/testmfs/test2:directories with goal 3 : 测试：分别向test1和test2写入1G的文件，可以统计出chunkserver上的空间分别减少了1G和3G。当设置的份数增加的时候写入的速度也慢了很多。$ dd if=/dev/zero of=test1/bb count=1024 bs=10240001024+0 records in1024+0 records out1048576000 bytes (1.0 GB) copied, 11.7595 seconds, 89.2 MB/s ```bash $ dd if=/dev/zero of=test2/bb4 count=1024 bs=10240001024+0 records in1024+0 records out1048576000 bytes (1.0 GB) copied, 18.9833 seconds, 55.2 MB/s 可以使用mfsfileinfo 查看每个文件分每个份数 删除后的文件可以在meta目录下看到可以直接mv ‘00000003|bigfile2’ undel/ 这样恢复文件各在删除test1和test2下删除1G的文件后总空间2分钟后减少了4G ```bash 启动顺序：masterserver->chunkserver->metalogserver/opt/mfs/sbin/mfsmaster start/opt/mfs/sbin/mfschunkserver start/opt/mfs/sbin/mfsmetalogger start