通过 tcpcopy(pf_ring) 对 BCM 5719 小包做的多组 benchmark

tcpcopy 在文档化、用户参与方式方面有很大的提升空间这个问题在之前已经专门说过。最终,在我们自己阅读代码的情况下,结合 pf_ring,坚持跑通了整个流程,用其对目前 BCM 5719 型号的网卡做了多组对比,结论见结尾。
使用 tcpcopy 做 benchmark,务必确定 tcpcopy 语法使用的正确性, 尽管互联网上绝大多数的文档以及官方文档都写的含糊不清。
比如,我们之前把过滤条件 -F "tcp and dst port 80" 写成了 -F "tcp and src port 80",造成的结果是在错误的基础上得出了一些奇葩的数据以及无法解释的现象,比如到 target server 的流量特别小,并且及其的不稳定,得到的 pps 也是非常的不稳定大到 400kpps/s,小到 20k  甚至 0。

这里列举我们测试环境使用的一组配置。
所有机器都是 RedHat 6.2 2.6.32-279.el6.x86_64,Tcpcopy 1.0 版本,PF_RING 6.0.1,BCM 5719,双网卡 bonding。另外,我们单台生产机器的流量都比较大,并且绝大多数都是 100B 以下的小包,所以对系统的要求还是比较高的。
为了避免后续的误解,先确定几个用语:
1. online server(OS): 即我们线上生产环境的机器
2. target server(TS): 是我们想做 benchmark 的那台机器,以测试其究竟能支撑多大的量
3. assistant server(AS): 是安装了 intercept 的机器
4. mirror server(MS): 通过 tcpcopy 的 mirror 工具把 OS 的流量复制到该台机器上

我们一共做了三大组 benchmark,每组下面包含若干小的 benchmark,包括:
1. tcpcopy + intercept
2. tcpcopy + intercept + tcpcopy mirror,加一个 mirror 是为了减少对 OS 的负载,这样 tcpcopy 在 MS 上运行
3. tcpcopy + intercept + 交换机 mirror,更直接的方式复制线上流量,保证对 OS 没有干扰,并且能保证 100% 全量复制 OS 的流量

Continue reading

PF_RING 对网络抓包性能的提升不仅仅是 30% – 40%

pf_ring 由于涉及的东西比较多,最初看的时候可能会云里雾里,不过多看几遍官方文档应该就能大致理解含义了。
安装的步骤可以看这里。 我建议还是自己跑一遍,这样能熟悉每个零部件的作用。要是实在没空,也可以直接用官方提供的 rpm, deb 安装。
这里提示下,除了编译出来的 pf_ring.ko 之外,如果你的 NIC 不支持 PF_RING™-aware driver,那么只能使用 mode 0,如果支持的话,可以使用 mode 1 以及 mode 2,三者在我们的系统上 benchmark 下来差距并不大,不过加载了 pf_ring.ko 跟不加载 pf_ring.ko 的差距那真是天壤之别了。基本目前主流的 Intel、Broadcom 的都支持(igb, ixgbe, e1000e, tg3, bnx2),注意,tg3 目前(10/18/2014)最新的稳定版本 6.0.1 并没有,需要使用 nightly builds 版本,PF_RING_aware/non-ZC-drivers/broadcom/tg3-3.136h,PF_RING_aware/non-ZC-drivers/2.6.x/broadcom/tg3/tg3-3.102 .2.6.x 目录下面的都是已经废弃的版本,就不要使用了。

一般的应用也不大用到 pf_ring,不过如果是一些 IDS、snort 之类的系统,就派上用场了。我们的情况有点特殊,某条产品线由于前端的机器网卡比较弱(BCM5719),再加上发过来的绝大多数都是 75B 以下的小包,导致 rx_discards 以每秒数 k 的恐怖值增加。最初想抓包看看发过来的都是什么样结构的包,结果普通的 tcpdump 就完全没法用了,传统的 BPF(libpcap) 抓包相比简直是弱爆了。下面两张图,一张是通过 ntopng(也是使用的传统的 pcap)分析的包的大小,跟 iptraf 结果一致,一个只抓到了 2% 不到的包:-(


有需求就有动力了,后来研究了下 pf_ring,情况立马变好转了。看看下面两个对比就知道了。

加载了 pf_ring 的:
$ sudo /var/tmp/pfring/PF_RING-6.0.1/userland/tcpdump-4.1.1/tcpdump   -i bond1 -n -c 1000000 -w tmp
tcpdump: listening on bond1, link-type EN10MB (Ethernet), capture size 8192 bytes
1000000 packets captured
1000000 packets received by filter
0 packets dropped by kernel

使用传统 libpcap 抓包的:
$ sudo tcpdump   -i bond1 -n -c 1000000 -w tmp
tcpdump: listening on bond1, link-type EN10MB (Ethernet), capture size 65535 bytes
1000000 packets captured
1722968 packets received by filter
722784 packets dropped by kernel
12139 packets dropped by interface

所以说,pf_ring 对抓包的提升不仅仅是官方宣传的 30%-40% 的提升,更是一种技术对另外一种技术的革新,以及实际生产效率的大幅度提升。
另外,广告下 ntop.org 这个网站,上面有不少有意思的玩意儿,ntop, ntopng,再比如代替 OpenDPI 的 nDPI。我曾经玩过 OpenDPI,没几天官方就不更新了,这东西最重要的是实时的分析目前主流的协议,好在 nDPI 站在巨人肩膀上发扬光大了。提醒一下,这个也仅仅做娱乐只用,如果要实打实的,还是去买设备。

venta 水洗机半定量使用测评

北京的空气有多么糟糕,我已经花了三个(1, 2, 3)篇幅来描述,并且给出了一些具体的防范措施。
但是有个问题一直没有提及,那就是湿度问题,这个不仅仅是北京的问题,整个北方都存在这个问题
太干了,干的非常不舒服,虽然有净化器,但是每天早上起来嗓子依然不舒服。最初我买了个两位数加湿器,然后,表现很差劲,由于北京水质不行,用久了出雾口会有白色的固体物质,应该就是钙镁离子;其次,还是由于水的问题,用久了能明显看到水箱里面剩余的水非常差;第三由于是出雾的,那种能看到明显白色雾气的,效果非常不好,能加湿的范围有限。后来用了纯水机,第一第二问题基本能解决,但是用久了还是能感觉到底座剩余的水有其他物质,再纯净的水一周不流通也就变成死水了,第三个问题没法解决,并且这成本变相提高了,一桶纯水的成本还是不低的。
为了解决覆盖范围小的问题,我买了台升级版的加湿器,最大的特点是水箱大,5L。但是新的问题又来了,一夜下来,由于过度加湿,整个卧室都是一股霉味,南方的同学应该深有体会吧。工程师应该定量的分析这些问题,所以我又搞了台湿度计来看看我的卧室究竟是什么情况,基本每天早上醒来的时候都是 75%+ 的湿度,还是加湿器离我床头有 3m 远的情况下,太恐怖。
情况至此,穷则思变。隔行如隔山,要在大陆混又不被坑,只能自己研究了。过程就不说了,结果很明显,出雾的直接排除,主流行业,基本是 Venta, Honeywell 以及其他。德国货看了下大概的原理,其实就是中学物理学的百叶(其实所有的净化器的基本原理都不复杂)。淘宝有家据说是大陆独家授权的,跟 amazon.com 一比较差距刺瞎人的双眼。并且好笑的事,大陆究竟有几个 venta 官方授权的代理商,哪些是被吊销代理资质的,这几个问题我花了点时间研究了下,觉得水太深。最终决定还是去美帝买吧。
半个月到家之后,拆箱,有点小失望,发现结构异常的简单,下面这个是 LW25 7L 水箱的构造

盖子更简单,看上去就是个可以调节功率的电风扇。
直接放清洗液加自来水,最初的两天数据显示效果不是很好,正常情况下,不开任何的加湿器,平均湿度在 15% 左右,21 度的室温已经部分达到人体舒适环境的标准了,结果开了两晚之后发现湿度也就在 45% 左右,离 50% 的舒适湿度还有不少差距,并且这是在卧室门密闭的情况下。
第三天把说明书翻了个遍,也没发现什么遗漏的细节。神奇的是,第三天晚上开始,湿度开始维持在了 60% 左右。确实好神奇的样子,为什么会这样我猜测可能是需要让卫生液充分混合才能发挥功效。后来就正常了。官方建议半个月换一次卫生液,下图是我用了 13 天水箱的情况(北京的情况还是一周一换吧):

效果还是很明显的,大颗粒的也就是我们肉眼看到的都沉淀在水下面,其实就是吸附 PM10 以下的物质了,老屋子甲醛之类的可以忽略,官方称的是可以吸附 10 微米的颗粒。这个我没法定量确定,一个靠谱的 PM2.5 counter 在 2k 左右(1k 以下大陆厂商的嚎头产品就别信了,ikair 的,曾经货没到手就让申请退款了,那什么墨迹的空气果也就只能当玩具而已,不能做科学定量)。不过可以肯定的是,每天早上醒来身体都很舒服,北京咳也消失了。我用了两年的 Honeywell 暂时可以退役了。另外,提醒一下各位,想靠 venta 做 pm2.5 清洁工作的还是别指望了,目前没有任何的证据表面水可以吸附 2.5,靠谱的还是传统的 HEPA 过滤网,venta 用来做加湿工作还是非常靠谱的,顺带清洁了一些大颗粒的物质。
目前我对室内环境非常满意,温度湿度都达到了人体适宜生活的标准,小熊猫也能在屋子里面蹦跶蹦跶了。

resolv.conf 的超时(timeout)与重试(attempts)机制

/etc/resolv.conf 有两个默认的值至关重要,一个是超时的 timeout,一个是重试的 attempts,默认情况下,前者是 5s 后者是 2 次。
这个估计很多工程师都不是很在意,一般情况下,使用默认的值倒没什么大问题,特殊情况我会在最后说明。

要测试,不要使用 dig, host, nslook 这类工具,因为他们并没有调用 resolver 的库,可以使用 getent 来测试。上面提到的只是一些诊断的工具,对于日常的应用来说,包括 web server、mail client、db 以及各种 app server 等等,任何使用 glibc resolver 都需要经过 resolv.conf 文件。

对于 libresolv 来说,只认 resolv.conf 的前三个 nameserver,所以写的再多也没什么意义。正常情况下,resolver 会从上至下进行解析,每个 nameserver 等待 timeout 的时间,如果一直到第三个都没结果,resolver 会重复上面的步骤 (attempts – 1) 次。

为了真正理解,例如下面这个场景:
search test.example.com example.com  
nameserver 192.168.0.1  
nameserver 192.168.0.2

假设 192.168.0.1 不返回结果(可能根本就不是台 DNS),我们假设需要解析 "www.devel",而这个仅仅在 www.devel.example.com 里面有记录,下面是整个执行的步骤:
1. "www.devel" on 192.168.0.1, wait until timeout (default 5 secs)
2. "www.devel" on 192.168.0.2, get reply: no such hostname
3. "www.devel" on 192.168.0.1, wait until timeout (default 5 secs)
4. "www.devel" on 192.168.0.2, get reply: no such hostname
5. "www.devel.test.example.com" on 192.168.0.1, wait until timeout (default 5 secs)
6. "www.devel.test.example.com" on 192.168.0.2, reply no such hostname
7. "www.devel.test.example.com" on 192.168.0.1, wait until timeout (default 5 secs)
8. "www.devel.test.example.com" on 192.168.0.2, reply no such hostname
9. "www.devel.example.com" on 192.168.0.1, wait until timeout (default 5 secs)
10. "www.devel.example.com" on 192.168.0.2, reply with IP address

默认情况下是 5s 超时,我做了两个简单的测试,把 resolv.conf 的前三个 nameserver 全部换成不存在的 1.1.1.1, 2.2.2.2, 3.3.3.3,然后可以观察下面 strace 跟踪的结果,对于 ping 以及 getent 来说,已经算是上层的应用结果了。
1. strace -t getent hosts baidu.com
2. strace ping baidu.com

把 timeout 设置为 1s 的结果可以看下面这个测试结果:
strace -t ping baidu.com(options timeout:1)

对于生产有什么意义了?
对于任何的代码,不管何种形式的(HTTP 的也好,DB 的连接也罢),只要是一端对另外一端的连接,都应该加上超时重试以及异常处理的。上面其实一共涉及三个点:
1. 超时,目前绝大多数的 API 都支持这类参数,包括我们线上用的 grequestsMySQLdb 等等
2. 重试,对于代码层面同样重要,跟上面类似
3. 异常处理,好的代码对于无法连接或者连接超时等问题应该及时的抛出异常打 log,而不是什么都没有,否则会加大问题定位的工作量,后期维护起来也会异常的麻烦。

这里有个有意思的脚本能检测最佳的 DNS。

最后,记得 dig, nslook 只会解析 resolv.conf 的内容,而不会解析 hosts 里面内容,所以如果想让 dig 解析 hosts 里面的内容,可以通过 dnsmasq 实现。

ref:
https://access.redhat.com/solutions/21420

http://serverfault.com/questions/562079/adjusting-how-long-linux-takes-to-fail-over-to-backup-dns-server-listed-in-resol