山寨智能家居

脑子抽了,买了个"智能"插座,这个插座有多智能了,说白了就是插座安装了 wifi 模块,让他连接到家里的路由器上,然后你就可以在任何地方控制插座的开关了。
买这玩意的本意是想夏天的时候在我未到家的时候提前帮我把空调、净化器开下来。买回来之后发现完全没用:
1. 一个这个插座只支持一个设备,所以想让空调、净化器同时工作的话,需要两个。
2. 即使有两个还是没用,通过手机打开 wifi 开关了,空调跟净化器都处于有电的状态了,如果你不按空调遥控器的开关、不按净化器的开关是无法工作的。
3. 即使都按了两者的电源开关,依然要调节空调温度、净化器的工作状态来达到你的需求,所以这一步怎么都没法让插座帮你完成。

据说现在市面有那种记忆功能的空调模块,不过依然没有通用性可言,空调可以用了,净化器怎么办?
后来,我就把这 wifi 插座当总闸来用了,离家或者有时忘关了就用手机关下,这样我房间里所有的电都断了,算是个废物再利用吧。


最新发现,我的加湿器可以在不用任何设置的情况下配合这个山寨机器自动的开始加湿工作 ;-)

Velocity/SACC 2013

今年参加了两场会议,一场 velocity,一场 SACC,二者举办的时间紧靠在一起。写篇博客简单概括一下。

Velocity 2013
今年的整体状况明显比不上去年。
上午唯一有兴趣的就是知道了 OmniTI 这家公司,简单的了解了下,跟 percona、palominodb 做的事有那么点类似,当然方向不完全一样,都是提供技术支持的,不过不是那种简单的外包形式,做的事情都蛮有意义的,也开源了不少的工具、产品,确实值得我们学习。大陆最近几年也冒出了一些类似的公司,尤其在 db 这块,市场还是蛮大的。

下午听了个《挑战与机遇共存——超大规模网络应用的运维》,得到的信息太少,而唯一有用的些信息跟我目前的工作联系不是很大。
还听了个《58统一监管平台系统分析与设计》,思路大致都差不多,没有什么太大的差别,不过看演讲者讲的如此的没底气,感觉是一个半残品的样子。不过这次交流下来,也让我明确了一点,没有一个系统能够完全的胜任目前所有的工作,很多时候,你是没法满足一些个性化的需求的,只能再单独的开发或者想其他的办法。
接着是《淘宝数据采集分析工具——Tsar》,有意思的,这个东西能将结果倒入到 nagios 里面,这是不是说明我们的干爹还在部分的使用 nagios 这个非常经典的监控系统了。不过由于只有一个人开发,并且更新的不是很积极,我不是很看好这个工具的发展,还是老老实实的用用 sar 这类经典的工具,虽然功能上可以不及 tsar。真正火的项目、工具一定是有一个完整的生态圈,一帮闲的无聊的人在贡献代码,一帮闲的无聊的人在使用他们,不停的给他们报 bug、提需求。另外一点是,这又一次的印证了上面说的,没有一个能满足所有需求的工具。

Continue reading

10G(82599EB) 网卡测试优化(jumbo frame, tcp win scaling)

1. 开启 jumbo frame
开启之前:
# netperf  -H 192.168.10.2  -t TCP_STREAM -c -C -l 10
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.10.2 () port 0 AF_INET
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % S      us/KB   us/KB

 87380  16384  16384    10.00      9394.05   2.68     2.46     0.561   0.516  

对于 2900, 4000/4500, 6000/6500 系列的,可以看这里。我们这里使用的是 N5K:
sw 上:
N5K(config)#policy-map type network-qos jumbo
N5K(config-pmap-nq)#class type network-qos class-default
N5K(config-pmap-c-nq)#mtu 900
N5K(config-pmap-c-nq)#exit
N5K(config-pmap-nq)#exit
N5K(config)#system qos
N5K(config-sys-qos)#service-policy type network-qos jumbo

server:
# ifconfig eth2 mtu 9000
永久写入:
# vi /etc/sysconfig/network-script/ifcfg-eth2
MTU="9000"

测试:
# ip route get 192.168.10.2

开启之后,效果十分的明显,达到了 9.9Gbps:
# netperf  -H 192.168.10.2  -l 15 -c -C -t TCP_SENDFILE -f /boot/initramfs-2.6.32-220.el6.x86_64.img  -f g
TCP SENDFILE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.10.2 () port 0 AF_INET
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^9bits/s  % S      % S      us/KB   us/KB
 87380  16384  16384    15.00         9.90   2.15     2.91     0.427   0.578  

注意,jambo frame 是需要端到端的开启的,即 server-sw-server,只要有一方没有开启都无法实现。

2. tcp_window_scaling 对网络的影响
这个参数主要是在 tcp win size > 2^16(64Kb) 时发挥作用,默认 tcp_window_scaling 是开启的:
# cat /proc/sys/net/ipv4/tcp_window_scaling
1
# netperf  -H 192.168.10.2  -P1 -l 30
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.10.2 () port 0 AF_INET
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  
 87380  16384  16384    30.00    9411.50   


将 server 端的关闭:
# echo 0 > !$
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
# netperf  -H 192.168.10.2  -P1 -l 30
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.10.2 () port 0 AF_INET
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  
 87380  16384  16384    30.00    2323.36   

只要有一端不开启,吞吐只能维持在 2Gbps 左右。当然,可以通过 interrupt coalescing 来部分的提高吞吐。

10G(82599EB) 网卡测试优化(总)

在正式测试优化之前,需要熟悉下,一个包从进入 NIC 到 userspace 的处理过程(1, 2, 3)。 
服务器硬件的基本(cs 有微小差异,可忽略不计)配置为 E5-2630×2, 8Gx8, 6x600G 10krpm, raid 10。系统为 RedHat 6.2 2.6.32-279.el6.x86_64。交换机为 Nexus5548, 5.1(3)N2(1)。关于设备之间的连接,正常多膜(SFP-10G-SR(=))的足够了,但是要注意区分下不同波长(850nm/1310nm)的模块。
服务器的网卡为 82599EB 芯片,x520-2,PCIe x8, 5GT/s:
# lspci -vvv -s | grep net -A 20 -B 20
81:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
    Subsystem: Intel Corporation Ethernet Server Adapter X520-2
        …
        Capabilities: [40] Power Management version 3
        Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
        Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
    Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
        Address: 0000000000000000  Data: 0000
        Masking: 00000000  Pending: 00000000
    Capabilities: [70] MSI-X: Enable+ Count=64 Masked-
        Vector table: BAR=4 offset=00000000
        PBA: BAR=4 offset=00002000
    Capabilities: [a0] Express (v2) Endpoint, MSI 00
        DevCap:    MaxPayload 512 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
            ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
        DevCtl:    Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
            RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
            MaxPayload 256 bytes, MaxReadReq 512 bytes
        DevSta:    CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
        LnkCap:    Port #2, Speed 5GT/s, Width x8, ASPM L0s, Latency L0 <1us, L1 <8us
                        ClockPM- Surprise- LLActRep- BwNot-
        LnkCtl:    ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
            ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
        LnkSta:    Speed 5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
        
ixgbe 支持的众多参数,比 broadcom57xx, intel i350 档次明显高很多:
# modinfo ixgbe
parm:           InterruptType:Change Interrupt Mode (0=Legacy, 1=MSI, 2=MSI-X), default IntMode (deprecated) (array of int)
parm:           IntMode:Change Interrupt Mode (0=Legacy, 1=MSI, 2=MSI-X), default 2 (array of int)
parm:           MQ:Disable or enable Multiple Queues, default 1 (array of int)
parm:           DCA:Disable or enable Direct Cache Access, 0=disabled, 1=descriptor only, 2=descriptor and data (array of int)
parm:           RSS:Number of Receive-Side Scaling Descriptor Queues, default 0=number of cpus (array of int)
parm:           VMDQ:Number of Virtual Machine Device Queues: 0/1 = disable, 2-16 enable (default=8) (array of int)
parm:           max_vfs:Number of Virtual Functions: 0 = disable (default), 1-63 = enable this many VFs (array of int)
parm:           L2LBen:L2 Loopback Enable: 0 = disable, 1 = enable (default) (array of int)
parm:           InterruptThrottleRate:Maximum interrupts per second, per vector, (0,1,956-488281), default 1 (array of int)
parm:           LLIPort:Low Latency Interrupt TCP Port (0-65535) (array of int)
parm:           LLIPush:Low Latency Interrupt on TCP Push flag (0,1) (array of int)
parm:           LLISize:Low Latency Interrupt on Packet Size (0-1500) (array of int)
parm:           LLIEType:Low Latency Interrupt Ethernet Protocol Type (array of int)
parm:           LLIVLANP:Low Latency Interrupt on VLAN priority threshold (array of int)
parm:           FdirPballoc:Flow Director packet buffer allocation level:
            1 = 8k hash filters or 2k perfect filters
            2 = 16k hash filters or 4k perfect filters
            3 = 32k hash filters or 8k perfect filters (array of int)
parm:           AtrSampleRate:Software ATR Tx packet sample rate (array of int)
parm:           FCoE:Disable or enable FCoE Offload, default 1 (array of int)
parm:           LRO:Large Receive Offload (0,1), default 1 = on (array of int)
parm:           allow_unsupported_sfp:Allow unsupported and untested SFP+ modules on 82599 based adapters, default 0 = Disable (array of int)

各个 parm 的含义可以看这里

测试监控的工具,这个很早之前都有提到。包括如下的一些:
* iftop
* jnettop
* iptraf
* nethogs
* vnstat
* ibmonitor
* iperf
* netserver
* ntop
* cacti(需要安装 Realtime plugins)
* mpstat
* vmstat
* netstat
* lspci
* dropwatch
* ifconfig
* ip

关于 netstat,使用不同的参数,读取的源文件不大一样,比如,读取 /proc/net/tcp 在连接数比较大的时候就很慢,而诸如 /proc/net/dev, /prco/net/unix 则相对会快的多。

而对于做 tweak 来说,主要集中在 ethtool, sysctl, ifconfig, setpci 这几个工具之间。

ping 延时跟千兆比基本不变,维持在 0.2ms 左右。在进行压测期间,会增加到 2ms 左右。以下的都是在未对服务器交换机做任何优化之前的测量结果,即所有的都是默认设置。 整个过程主要涉及 iperf, netserver 两个工具。

关于 iperf 的使用,需要注意几点:
# iperf -c 192.168.10.2 -t 20 –format KBytes -d/-r -x CMS -w 400
如果想让 c 和 s 同时往对端发送流量,可以在 c 端使用 -d 参数;如果想依次进行,可以使用 -r 参数。
双方同时发 9.35 左右,单方向发 9.41 左右。

还有一点需要注意,有没有 -P 参数,即是否使用多线程,对测试的影响还是很大的,尤其涉及到中断时。

netperf 相比更为专业,使用也比较简单,最常见的如下:
# netperf  -H 192.168.10.2  -l 15 -c -C -f g — -m 8192 -r 1024,1024

可以先对 localhost 发起一个请求确认网卡有无异常,正常情况下应该是打满了:
# netperf  -f g
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost () port 0 AF_INET
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^9bits/sec  

 87380  16384  16384    10.00      10.75   

默认会使用 TCP_STREAM 也就是 send() 来发包,也可以通过 TCP_SENDFILE 调用 sendfile() 来测试,不过在测试达到 9.4G 之后,使用 sendfile 提升效果微乎其微。

接下来几篇博客会从不同的方面总结一些通用的操作优化,每一个测试都是相互独立的。最终的目的就是充分使用带宽,打满 10G,系统的负载尽可能的低,latency 尽可能的低。并且,更多的是集中在优化而非测试上,因此并没有正式的测试报告,更没有漂亮的图表。在测试过程中,可以通过下面的命令观察基本的系统负载状况:
# sar -n DEV -u 10 -P ALL
# mpstat -P ALL 5
当然,最基本的 top 也能看出不少的数据。

对于 BIOS 方面的问题,基本是在 "profile" 上的选择上,细化就是 C1E, Turbo boost, HT 等问题,不再多说。有点需要注意的是,关于 CPU freq 的选择,需要着重注意下。

以下的几篇关于 10G 网卡测试优化的博客参考了不少下面的两个经典的文档,在此表示感谢。时间都是 09 年左右的,但是绝大部分的实践都是适用的。
一个是 IBM 写的 《Tuning 10Gb network cards on Linux》,另外一个是 redhat 在 08 年的峰会上分享的名为 《10 Gb Ethernet》,他的加强改良版出现在 12 年《achieving top network performance这是他的视频。

zabbix 性能方面的优化(一)

下面的操作主要集中在 zabbix server/proxy/agent 本身,涉及到 DB 的操作会在zabbix 性能方面的优化(二)记录。
其所有的来源是《abc of zabbix performace tuning》这个幻灯片。总结的很详细。

我这里就重点总结几个问题。
最终的目的是要使得 zabbix[queue] 足够的低,同时注意看看其他的 internal statisitcs。

最明显的是 zabbix_server.conf 文件里面各个 Start*  指令的调整。这个官方的文档说的也不是很清楚,需要自己慢慢实践调整,太大太小都会造成 queue 的飙升。需要针对目前的 hosts/items 的数量级别进行调整。

开启 DebugLevel 可以在 log 里面看到当前系统的状况。

能用 Zabbix agent (active) 的别用 Zabbix agent。

其他的参见那个幻灯片就好了。

Elasticsearch 跟 VC(venture capital)

在 IT 行业,想开个公司做大做好最后大家都能吃香喝辣,基本是离不开幕后的 VC,不管是国外的 Google、Facebook、Twitter,还是国内的 Baidu、人人、微博,包括我司在内的,统统离不开这帮干爹。不仅仅是 IT/TMT 行业,连北京满大街的粥店火锅店卖鸡蛋的开房的都会有 VC 的帮助。
总之,VC 的产生总的来看是一件好事,你愿意出钱我愿意烧钱,大家做的都是心甘情愿,赢了大家按协议分钱退出;输了优先清算点东西,也图不到个什么。除非 founder 都是不缺钱的土壕(canonical 的 CEO),一般的创业者还是离不开 VC 的。
之前在火车上把桂曙光老师写的《创业之初你不可不知的融资知识》看了两遍,对VC/LP/GP/Option/Term sheet 等这些概念有了个大致的了解,再加上本身对 IT 跟 VC 这两个方向都比较感兴趣,而且这两者基本可以说是臭气相投,谁也离不开谁(相比 TMT,VC 基本不会投资芯片、新药研发这类项目,因为前者更加的来钱来的快,更容易 copy),平时也比较关注这方面的动态。

下面进入正题,Elasticsearch,主要说说 ES 跟 VC 的关系。

对于一款开源的产品,我了解的大部分运作模式基本有下列几种:

  1. 如果是从公司诞生的,比如像 linkedin 开源的 kafka,Twitter 开源的 twemproxy 等等,这类自然不用担心"销路"问题,这类产品都是有专职的工程师去开发,说白了,就是公司花钱雇这帮人来专门的维护开源产品。如果发展的不错,还能被 Apache 基金会纳为顶级开源项目,比如上面提到的 Kafka,这个对公司绝对是一种莫大的荣誉,就像如果你是一名 ASF 的 committers,同样是一个非常大的荣誉。
  2. 更多的是像下面描述的那样。很多时候纯粹是个人不满于现状,于是开发了一个更好用的工具,然后在 github 上开源出来了,然后世界上对现状不满意的人还蛮多的,那些人发现了这个项目之后,认为这是个非常好的东西,确实能够解决自身的需求。于是本着  don't reinvent the wheel 的原则,大家就一起来贡献代码了,然后,然后就越来越火了。不过这类模式有个问题就是,很多都是凭作者的兴趣爱好感觉来走,他们的专职工作并不在此,如果这个项目很火,有很多人贡献代码还好,如果这个项目不是很火,可能适用的领域很狭窄,可能最活跃的贡献者就是原作者本人,如果哪天作者说迫于生计不想再继续了,或者没时间了,或者没兴趣了,这个项目基本就死了。这个也是目前 Linux 下大多数软件工具产生的方式。看看那些项目主页出现的 "donate me" 就知道了。
  3. 最后一种也是最近几年比较火的方式,找 VC。虽然之前也有,但是一直都比较的低调,最著名的就是 RedHat 了,早在 97 年的时候,Cygnus Solutions(99 年被 RedHat 收购) 就接受了第一笔 VC 投资,这同时也是开源软件领域的第一笔风资 。近几年,最有代表性的就是 Puppet 跟 Elasticsearch。开源项目找 VC 看上去比较矛盾,源代码都是是公开的,就在 github 上。那怎么赚钱了?不过仔细研究下就会发现一点都不矛盾。这个应该是所有开源软件的套路了:
  • 卖服务,包括企业培训,7×24 的生产环境支持,快速的 bug 修复等等。
  • 还有一小部分的是收费的会开放更多的功能而免费的版本只提供基本的功能,这类的在各个 repo 里面能看到不少。

为什么要把 Elasticsearch 单独列出来说了?我认为这是开源公司跟 VC 合作的一个比较成功的案例,虽然说成功为时过早,不过从目前的发展来看,前景是相当的令人兴奋,完暴 Solr。

从去年中旬起,我们开始调研开源的日志收集处理方案,当时如果你 Google elasticsearch 同时肯定会出现 logstash/graylog2/kibana 等与之配套的条目,并且当时这几个(graylog2 目前已经不在主流了,接下来不提他了,Elasticsearch/logstash/kibana 已成为 log 收集处理的工业标准)项目都是各自独立发展的:

ES 在 12 年 11 月完成了 A 轮 $10M 的融资。紧接着,3 个月之后(这么快?),也就是 13 年 1 月 ES 宣布了 B 轮融资。从他们的对外报告中可以看到,这 $24M 的费用主要会用在哪里,其中之一就是人才的招聘。接着从他们的 blog 中可以明显的看到他们加快了招人、扩展海外市场(US)的步伐。插个话,说说我们的经历,我正好是在宣布拿到 A 轮的时候进入的,接着就经历了从 0 开始的大张旗鼓的数据中心建设,这个跟当年对外的口径基本一致。目前每个月仅仅花在带宽服务器网络设备上的费用就多的吓人,至于花在人上面的费用,大概数数应该都是能算得出来的。
Aug 27, 2013, Jordan Sissel 跟他的 logstash 加入到了 Elasticsearch,而 Rashid Khan 先前也加入到了 ES。再细挖他们的 blog(我疑惑的是,他们把员工的信息补充的如此详细,从 twitter 到 linkedin,不怕别别的公司挖墙脚么?) 就会发现,ES 把几乎跟其周边生态系统相关的人都挖过来了,从各个语言客户端的 API 作者到有经验的使用者传道者,只要是跟其相关的,统统都挖过来了。这个完全没问题,搞开源重要的一点就是要形成一个生态系统,看看 Hadoop 就知道了,孤立的搞下去基本会完蛋。挖人是需要花费很高的代价的,除了要晓之以礼,动之以情之外,Salary Package 是绝对不会低的:
We pay our people very well – probably above the industry average.
再者,ES 在 Bay Area 开设了除 Netherlands 的第二个办公室。除了这些,对外开放的免费的演讲,开设 Webinar 都是需要时间跟费用的。不说其他的,一天的下午茶零食,如果再包含午餐、晚餐,开销就不小了。
而上面这些费用,也只有 VC 才能供得起,ES 前后拿到的一共 $34M 估计也够花一阵子了。

从上面的可以看到,VC 不但对于传统意义上的[移动]互联网有比较大的帮助,对于这类研发开源软件的公司同样有不小的帮助,只要是一个注册了的公司,都离不开上面的这些日常开销,差别在于多少的问题。比如,ES 允许员工 home based,这能节省一定的房租开销,不过其他方面该花的还是要花的。

不知道有没有人好奇这些 VC 的钱都哪里来的?VC 的都是 LP 给的,LP 的钱就各种来路了。再者,我理解的天使投资跟 VC 的界限并不是很明显,所以一起说了。

  • 天使投资的钱一般都是自己的,一般的套路都是有幸经历了某家公司的 IPO,作为早起员工,拿到了一大笔的 option,30 财富自由退休,不能再继续的苦逼写代码了,于是把钱拿出来做投资,虽说是风险投资,不过最终肯定是稳赚的,这就是上面说的不会投资芯片、新药这类需要大量投资而不容易除成果的产业的原因,门槛很高;要么就是黑钱了,比如那个前段时间被搞的薛蛮子。
  • 对于 VC,这个就是 LP 的了。LP 的大多数都是一些机构投资者,比如公共养老基金、保险公司等等;再者就是跟天使投资类似的富有的个人,据说现在不少的煤老板都成了 LP 了。
  • 另外,现在不少互联网公司也要一起近来玩,比如 Google Ventures,他就投资了 Puppet;再比如阿里巴巴集团战略投资部,也投资收购了不少公司

大致就说这么多了,最后放一段 ES 拍的视频,制作精良鼓舞人心 ;-)