香山温泉小游

25 号 offsite,下午去爬了爬香山,这个跟南京的中山陵,北京的天安门一样,不知道还要去多少次。不过正好把前几天刚到的 xz-1 拿出去练练手,由于选了条非正常人类走的路,导致被不知道是植物还是动物的东西扎了几次,最开始是非常的痒还带着疼痛,过了大概半个小时就消失了(没事吧
下面是几张香山的小图。

某人说这个貌似对焦对错了?

晚上去了顺景温泉,号称全球最大的室内温泉,吃完自助泡了两小时,把能泡的都走了遍,算是大概熟悉了下整体情况,最后睡在大厅的,除了有呼声,其他还都不错。

Continue reading

取代 netstat 的 ss

之前只知道有个 -s 能看到目前系统连接数的整体情况,实际上 ss 远比这个强大,远比 netstat 强大,最大的特点就是快。
$ ss -s

本地打开的端口:
$ ss -l
$ ss -ln
$ ss -lp

TCP,UDP,RAW,UNIX sockets:
$ ss -t -a
$ ss -u -a
$ ss -w -a
$ ss -x -a

如果某些协议修改了端口,要么要修改 services 对应的 port/service-name 要么就要直接使用数值的方式显示,比如我把 sshd 的端口修改成 11111:
$ ss -o state established '( dport = :11111 or sport = :11111 )' -p
Recv-Q Send-Q                                                                           Local Address:Port                                                                               Peer Address:Port  
0      256                                                                               11.11.111.21:11111                                                                           222.222.222.162:47868    timer:(on,207ms,0)
0      0                                                                                 11.11.111.21:11111                                                                           222.222.222.162:64872    timer:(keepalive,73min,0)
0      0                                                                                  192.18.10.15:11111                                                                               192.18.10.14:32984    timer:(keepalive,50min,0)

如果不修改 services 而直接使用的话,会找不到:
$ ss -o state established '( dport = :ssh or sport = :ssh )' -p
Recv-Q Send-Q                                                                           Local Address:Port                                                                               Peer Address:Port  
Continue reading

NUMA 在 DB 上的一些问题

关于 NUMA (Non-Uniform Memory Access, 非一致性内存访问)的概念,可以看 MicroSHIT 的这篇文档。概括起来,NUMA 就是把 CPU 与特定的内存做绑定,这个在有好多物理 CUP 的情况下比较占优势。
而 NUMA 分为硬件的和软件的,硬件的有好几条系统总线,每条系统总线为一小组 CUP 服务,然后这一小组 CUP 有自己的内存;软件的跟软 RAID 类似,没有硬件的方式只能通过软件的方式实现了。
跟 NUMA 对应的是 SMP(Symmetric Multi-Processor, 对称多处理器),所有的 CUP 共享系统总线,当 CUP 增多时,系统总线会互相竞争强资源,自然就撑不住了,正常的 SMP 体系也就只能支持十来个 CPU,多了系统总线就会成为瓶颈。
现在还出现了个叫 MPP(Massive Parallel Processing) 的体系,比 NUMA 的扩展性更牛逼。
这里有张图比较形象的描述了这三者,可以参考一下。

说上面这段话是为了引出下文,在启动 mongo 的时候出现下面的 warning:
Thu Sep 7 15:47:30 [initandlisten] ** WARNING: You are running on a NUMA machine.
Thu Sep 7 15:47:30 [initandlisten] **          We suggest launching mongod like this to avoid performance problems:
Thu Sep 7 15:47:30 [initandlisten] **              numactl –interleave=all mongod [other options]

根据官方文档的解释,Linux, NUMA, MongoDB 这三者不是很和谐,如果当前硬件是 NUMA 的,可以把它给关了:
# numactl --interleave=all sudo -u mongodb mongod --port xxx  --logappend --logpath yyy --dbpath zzz

官方还建议将 vm.zone_reclaim_mode 设置为 0。系统给 NUMA node 分配内存,如果 NUMA node 已经满了,这时候,系统会为本地的 NUMA node 回收内存而不是将多出来的内存给 remote NUMA node,这样整体的性能会更好,但是在某些情况下,给 remote NUMA node 分配内存会比回收本地的 NUMA node 更好,这时候就需要将 zone_reclaim_mode 给关闭了。这篇文章记录了对于 web server/file server/email server 不设置为 0 的悲剧。这里还有一篇,描述了作者遇到的现象,因为遇到了内核 bug。

不过,真正起作用的其实还是 numactl,看了这篇文档所讲,抽取出来,NUMA 有几个内存分配的策略:
Continue reading

童年

晚上回小区,路上经过一对母女,孩子估计就几岁的样子,踩着个小踏板车,单脚的那种。风比较大,两人都带着帽子。

孩子:呜呜呜,你怎么不带我去的阿

妈妈:小宝贝儿阿,这个风太大了

孩子:(哭)

妈妈:这个点出去要回来要冻感冒了阿

孩子:你不带我玩了(继续哭)

虽没看到孩子哭的样子,不过想像那苦大仇深的样子,一边哭一边用手抹鼻涕,还顺便吹出几个泡泡。

哈哈 :=D

scp 出现 stalled 的分析

在使用 scp 进行一些大文件传输时,会出现 stalled 的情况,不外乎下面两个原因。

scp 对带宽的使用是贪婪的,因此有多少的带宽他就会使用多少(实际情况很复杂,并不全是贪婪的情况,也不是有多少用多少),但是如果一旦由于网络设备或者防火墙造成了一些延时,就会导致此次传输出现 TCP stalled。对此,可以通过限速解决,以 200Kbit/s 的速度进行传输:
$ scp -l 200 file dst:

另外还有个次要原因,可能是由于 Linux 下的 SACK 的造成。一般开启限速功能应该就能解决绝大多数的情况了。SACK 是什么请看这里
要使用 TCP option 中的 SACK,需要两端都支持。

根据这篇文章的描述,在局域网或者低延迟的网络中,就完全没有必要开启 SACK options 了,另外在很小的带宽下,比如 1Mbps 的情况下,同样没有必要开启这个选项。该选项可以在 "high bandwidth, lossy (or high delay)" 的情况下开启。因此出现 stalled 的情况一般都是在客户从公网连接某台服务器,带宽一般都是比较小的,瓶颈带宽在客户端这边,而不大可能是两台同一链路(连在同一台交换机)的服务器之间的数据传输。因此关闭 SACK 会比较有利传输:
# echo 0 > /proc/sys/net/ipv4/tcp_sack

ref:
http://daybydaylinux.blogspot.jp/2011/02/scp-stalled-during-big-files-transfer.html

netstat 中的 Recv/Send

netstat 查看当前的连接情况,会出现 Recv-Q 以及 Send-Q 的这两栏:
Proto Recv-Q Send-Q Local Address           Foreign Address         State     
tcp        0    180 111.111.111.111:80      110.194.127.254:39922   FIN_WAIT1 
tcp        0      0 111.111.111.111:80      112.64.188.117:49319    TIME_WAIT 
tcp        0      0 111.111.111.111:80      221.131.128.207:61285   TIME_WAIT 
tcp        0    180 111.111.111.111:80      119.180.158.228:1131    FIN_WAIT1 
tcp        0      1 111.111.111.111:80      175.136.68.117:40492    LAST_ACK  
tcp        0    180 111.111.111.111:80      218.85.96.248:34279     FIN_WAIT1 
tcp        0      1 111.111.111.111:80      212.58.162.182:26196    FIN_WAIT1 
tcp        0      0 111.111.111.111:80      211.140.5.110:48673     TIME_WAIT 
tcp        0      1 111.111.111.111:80      117.136.11.171:46403    FIN_WAIT1

我理解的是,Recv 的是数据还在缓存中,还没被进程读取,这个值就是还没被进程读取的 bytes;而 Send 则是发送队列中没有被远程主机确认的 bytes 数。
这两个值正常情况下应该为0,暂时的不为 0 可以理解,但是长期的非 0 则表明出现了一些问题。如果 Recv 长期的不为 0,则表明可能遭受了 DOS 攻击或者说是程序有点问题,进程根本就没有读取缓存中的数据(?我个人猜测而已);而 Send 不为 0 则表示了,则表示本地发送的数据超出了对发的接受能力。

ref:
http://www.enterprisenetworkingplanet.com/netos/article.php/3430561/Keep-an-Eye-on-Your-Linux-Systems-with-Netstat.htm