帖子

目前显示的是 三月, 2015的博文

雅虎北京研发中心正式关闭,我被裁了

如新闻所说,雅虎北京研发中心正式宣布关闭。所以,我也……

DELL R410 C-states引发的严重性能问题

图片
最近刚发现了DELL R410的BIOS缺陷导致的一个严重性能问题。通过更改BIOS设置,这些机器的性能提高了50%。现象我们组有一套流处理系统,它接收事件,处理,再转给下一个。这是一个计算密集型的程序,瓶颈在CPU上。当它发现它的处理速度跟不上的时候,它就开始丢事件。于是我们就增加了机器数量,以期望解决问题。实际结果却是变得更糟了,事件丢失比例大幅增加。原因是publisher的事件分发采用的是roundrobin的策略,新加的这几台机器的性能明显弱于其它机器,于是它们就拼命丢事件。但是,所有这些机器的CPU都是一样的啊。最主要的区别是,旧机器是HP,新机器是DELL的。上面的线是DELL的机器,下面的是HP的。峰值的CPU使用率,DELL的比HP的几乎高一倍。空闲时大约高50%左右。于是我开始调查为什么DELL的机器会比HP的慢。然后在DELL的机器的启动时的dmesg中找到了这样一句话:"p4-clockmod: Warning: EST-capable CPU detected. The acpi-cpufreq module offers voltage scaling in addition to frequency scaling. You should use that instead of p4-clockmod, if possible."并且,DELL机器的/proc/cpuinfo和HP的相比,cpu flags中少了est这个flag。还有一个区别是:根据/proc/cpuinfo中的信息,DELL的机器的CPU始终是满频(2.4G Hz)运行。而HP的机器则是时高时低,空闲的CPU都运行在1.6GHz。DELL机器的cpuinfo我列在了下面:processor15vendor_idGenuineIntelcpu family6model44model nameIntel(R) Xeon(R) CPU E5620 @ 2.40GHzstepping2cpu MHz2394.035cache size12288 KBphysical id0siblings8core id10cpu cores4apicid21initial apicid21fpuyesfpu_exceptionyescpuid level11wpye…

长连接与负载均衡

长连接和负载均衡都是服务器端常用的技术,但是它们碰在一起的时候麻烦就出现了。下面以google的kubernetes举例,说说麻烦在哪里。kubernetes是一个管理docker集群的东西。部署在kubernetes上的每个服务(service)由一个或多个pod组成。每个pod都有一个独立的IP。kubernetes希望利用IP层的负载均衡技术,让每个服务都对应一个独立的IP。这样,当pod发生迁移或者伸缩的时候,对使用它的人是不可见的。我想说的是,这样做是有问题的。假设服务S由podA和podB两个pod组成。客户端使用了固定大小的连接池,到服务S有100个连接。然后突然,podB死掉了。于是对客户端来说,连接池的数量就降低到了50。由于50个连接不够用,所以很快,客户端就向podA新建了50个连接,把总连接数量补到了100。然后podB恢复了。但是对于客户端来说,因为100个连接已经够用了,所以podB收不到任何请求。简单的结论是:假如一个服务由多个副本组成,并且客户端使用了长连接,那么客户端必须知晓副本的数量,否则服务端负载就会不均衡。假如连接本身是无状态的(例如HTTP),那么可以加入一个中间代理来解决负载均衡的问题,从而降低client端的复杂度。所以就kubernetes来说,无论你是用flannel、skydns,还是其它什么策略。只要存在长连接,客户端就必须主动去查kubernetes API来获知pods的真实IP。这个耦合及依赖是必须存在的。