最近有几个新的服务器，经常有一堆内存的报错。并且是服务上线后才发现的，dmesg里能看到很多错误信息，但是带外直接看sel log又没有异常。尝试了下使用memtester来测试。使用比较简单，直接编译安装后，放screen运行。Usage: memtester [-p physaddrbase][B|K|M|G] [loops]```bash ./memtester 7G 10测试7G内存，循环10次 [memtester](http://pyropus.ca/software/memtester/)
传统的VPS厂商对外的时候都会比较忌讳谈超卖的比例。不过linode的FAQ上直接说名的平均的情况，到是挺不错的。How many Linodes share a host? Linodes of the same plan are grouped together onto a host. We adjust the number of slots on each host according to its resources and hardware specification. On average, a Linode 1GB host has 40 Linodes on it. A Linode 2GB host has on average 20. Linode 4GB host: 10 Linodes; Linode 8GB host: 5; 结合到linode的套餐其实就能大概看明白了。 每个宿主机上能跑40个1G的VM（另外比如8G内存的不超过5G），那么说明其宿主机的内存配置还可能就48G的，料想这个FAQ可能只是针对今年升级前的老机型的。老的机型应该是2个Intel(R) Xeon(R) CPU L5520 4core的CPU，配上48G内存，磁盘做raid后容量2T左右。老机型就是把16个逻辑核平均当40个逻辑核卖。从今年最新的blog里面看到现在新的机型都是E5-2670，8core带HT。那么服务器应该内存也应该到64G或者96G了，而且现在的套餐里也多了16G内存的，在之前的48G机型这样会出现跨numa节点的访问，性能会很差。现在每个服务器上逻辑核总数32个，VM的密度不变的话单个宿主机能跑的VM数量可以翻一倍，可以节省很多机架费用(硬件价格不断下降，机架价格像房租一样不断上涨)。现在的每个VM用的都是8个core，看样子应该是开了numa，绑定了每个VM使用的CPU在一个numa节点上，这样只要没有出现跨节点的内存分配的话，VM的性能会比没有开numa的好30%左右。不同套餐的用户使用权重来分优先级。 blog另外从linode的blog上也能看到最新的网络架构，7K+5K+2K，比较常见的架构了。 linode这种做最轻量级的VPS厂商其实还是比较容易的，主要是看公司整体考虑，适当的提高价格，避免控制超卖的比例不够时亏本，类似brust这种超卖应该都是无比严重。。
线上有的服务器停机应用比较大，单身如果又遇到网络驱动之类的有bug那就麻烦了，徘徊于等死与找死之间。想着所有的机器都是双上联做了bond的，可不可以一次升级一个网卡呢？做了bond单次挂1个网卡应该是无损的。 上周把我的这个想法给内核组的同学说了，没有想到这周就给出了具体的方案。我自己稍微测试了下，把脚本的一些细节地方修改了下昨天测试2个网卡连续切换驱动10次无丢包。 不过有实际的大流量的时候还有待验证。
前面试过openwrt下把个别的端口单独划分到独立的vlan，使得连到这个端口的机器的IP是单独一个vlan的IP。今天测试了一下单个端口直接绑定到多个vlan，客户端机器自己使用vlan id来标记。 config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config interface 'lan' option ifname 'eth1.0' option type 'bridge' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' config interface 'lan1' option ifname 'eth1.1' option type 'bridge' option proto 'static' option ipaddr '192.168.100.1' option netmask '255.255.255.0' config interface 'lan2' option ifname 'eth1.2' option type 'bridge' option proto 'static' option ipaddr '192.168.200.1' option netmask '255.255.255.0' config interface 'wan' option ifname 'eth0' option proto 'dhcp' config interface 'wwan' option proto 'dhcp' config switch eth1 option re set 1 option enable_vlan 1 config switch_vlan option device eth1 option vlan 0 option ports '0 1 2t 5*' config switch_vlan option device eth1 option vlan 1 option ports '2t 5*' config switch_vlan option device eth1 option vlan 2 option ports '2t 5*' 以上就是把db120的eth3除了在默认的vlan 0内，还在vlan1和vlan2里面，vlan1使用192.168.100.0/24的段，而vlan2使用192.168.200.0/24的段。dnsmasq加上对于的dhcp配置 ...
内部搞了个apt源，简单记录一下，主要参考了:http://www.debian-administration.org/articles/286 新建立目录结构mkdir test/{conf,dists,incoming,indices,logs,pool,project,tmp} 2.新建配置文件 2.1 conf/distributionsOrigin: GNUerLabel: GNUer’s repositoryCodename: testingArchitectures: amd64Components: mainDescription: Description of repository you are creating2.2 conf/optionsverboseask-passphrasebasedir . 3.包的维护 导入包需要使用reprepro reprepro -b /home/mirrors/test/ includedeb testing /home/test_deb/dropbox_1.6.0_amd64.deb删除包reprepro -v -b /home/mirrors/test/ remove testing dropbox apt源的配置新增deb http://192.168.2.2/test testing main
最近测试DNS服务器直接和交换机跑OSPF。2上联网卡分别接入2交换机，形成邻居。服务器不设置静态的默认路由，通过和上层路由器交换路由信息的时候学习默认路由。另外的办公网接入的网卡只是绑定了IP。因为是在测试环境所以有个问题是上联的链路其实是不能访问外网的。我就单独设置了一下策略路由解决。需要达到的目的其实只是能从办公网络ssh登陆服务器，服务器上能访问部分外网（比如8.8.8.8进行DNS解析）。配置其实比较简单：1. 先新增策略路由#cat /etc/iproute2/rt_tables## reserved values#255 local254 main253 default0 unspec## local200 dns 2.给table 200增加默认的路由#cat route-eth0table dns 192.1.159.0/24 via 192.1.159.254 dev eth0table dns default via 192.1.159.254 dev eth0 ip route add 192.1.159.0/24 via 192.1.159.254 dev eth0 table dnsip route add default via 192.1.159.254 dev eth0 table dns ip rule add to 8.8.8.8 table dnsip rule add from 192.1.159.210 table dnsip rule add to 192.242.252.0/24 table dns
gnome3下现在屏幕的默认亮度不能保存，网上搜了一圈简单的方式是在rc.local里加 echo 70 > /sys/class/backlight/acpi_video0/brightness
昨天遇到有同事帮忙看一下信任登录打通的问题，已经把跳板机的公钥加到服务器上了，但是每次登录都要输入密码。ssh -v看了一下能成功登录的机器是debug1: Next authentication method: publickeydebug1: Trying private key: /home/admin/.ssh/identitydebug1: Offering public key: /home/admin/.ssh/id_rsadebug1: Server accepts key: pkalg ssh-rsa blen 277debug1: read PEM private key done: type RSAdebug1: Authentication succeeded (publickey).debug1: channel 0: new [client-session]debug1: Entering interactive session.不能成功登录的机器是debug1: Next authentication method: publickeydebug1: Trying private key: /home/admin/.ssh/identitydebug1: Offering public key: /home/admin/.ssh/id_rsadebug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,passworddebug1: Trying private key: /home/admin/.ssh/id_dsadebug1: Next authentication method: password区别是不能成功登录的服务器没有接受到私钥。查看一下是.ssh整个目录的宿主uid是有问题：# stat .sshFile: “.ssh”Size: 4096 Blocks: 8 IO Block: 4096 目录Device: ca20h/51744d Inode: 311305 Links: 2Access: (0755/drwxr-xr-x) Uid: ( 500/ UNKNOWN) Gid: ( 500/ XXX)Access: 2013-06-15 23:04:15.000000000 +0800Modify: 2013-04-03 11:24:29.000000000 +0800Change: 2013-06-15 23:04:15.000000000 +0800 用户的UID其实不是500，但是.ssh的UID却被设置为了500，chown xxx:xxx .ssh -R后解决。 ...
近来比较火的一个问题就是DNS放大攻击，详细的介绍可以参考这里。cloudflare被攻击的流量超过20G。这个攻击思路其实和smurf攻击类似。smurf攻击是对一个子网的广播地址发起一个伪造IP源的ICMP包，这样这个子网的所有机器都会icmp-reply到这个伪造的IP地址上。造成只需要少量的肉鸡就能引起很大的攻击流量。而DNS放大攻击是伪造一个DNS查询的报文，源地址改成想要攻击的IP。单个查询的包64字节，如果是ANY类型查询(或者DNSSEC记录)，那么回复报文一般会大几十倍。当然，如果攻击者自己制造一个很大的TXT记录，那么可能返回的更大的报文，攻击的强度就会更大。这样2M带宽的肉鸡，能制造的攻击流量就能到几百兆了，几十个G攻击流量很容易制造。 [这里](http://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack)
其实都是摘自TCP/IP详解和HTTP权威指南上面的。 1.http事务的时延主要是指我们要发起一个请求，需要先进行dns查询，然后对对应的IP:PORT发起请求。整个过程总每个环境都可能造成时延，比如dns查询，连接建立，服务器响应，请求和响应报文的大小。2.TCP三次握手。连接建立的三次握手也比较耗时，尤其是client和server相隔很远的时候物理距离造成的光传播时间本来就长，而且可能网络之类不佳造成重传等等都可能使得连接的建立耗时很久。对于返回内容比较少的情况下，连接建立时间占整体时间的比例会相对较大。3.延迟确认简单地说server向client连续发了几个组的数据，client其实不会直针对每个组都去发ACK确认，而是会在收到第一组数据后启动延迟定时器，过100-200ms再看看现在收到的所有组有那些，能连续组装起来的，就直接把最大的序号的组确认一下就OK了。4.TCP慢启动TCP的慢启动本来是为了避免快的发送方到慢的接受方这样的情况。所有每个连接连接后，开始发送的数据量比较小，比如一个分组，加入对方收到好ACK确认了，那么下次就直接发2个分组的数据，以此类推。因此新的连接比已经完成“调谐”的连接要慢一些，如果双方是持续连接（keepalive），那么效果就会比较好。5.Nagle算法与TCP_NODELAYnagle算法本来是为了避免每次发一个小的分组，造成网络性能非常差。Nagle算法要求一个TCP连接上最多只有一个未被确认的完成的小分组，但因为确认过程本身是由延迟定时器（100-200ms）来完成所以可能会造成额外的延迟。一般来说nagle算法会在对方确认的越快就会发送的最快，比较自适应。但是如果是类似telnet这种远程登录操作，或者是X系统里面鼠标的一个移动，那们都是希望能尽量实时，不要延迟，基本都会选择TCP_NODELAY选项关闭nagle算法。6.TIME_WAIT累计和端口耗尽。每个socket其实是由``` 源ip:源port，目标IP，目标port 当然，假如后面有很多机器，那么因为目标IP不同，实际情况会好些。