PHP memcached扩展长连接失效排查

php的mcmcached扩展参数众多,文档简陋,内部实现复杂,无奈phper没有什么好的选择

最近有一个比较苦恼的问题,偶发memcached连接timeout,报警趋势图表现出一瞬间毛刺,从日志分析看故障机有时候集中在若干server端IP,有时候集中在若干client端IP,由于服务容器化后已经迁移到公有云上,这些IP都是容器级很难直接观察出共性,一直怀疑是物理机层面异常导致,但发生频率比较没有规律,抓包效率不太高,最终经过几天与云方技术伙伴排查发现是物理网卡的队列占满,报文丢弃,根因在于连接浪涌。厂商给出的内部解决方案是 测试看队列长度是否可以调大,如果可以调大也只能打冷补丁,更新周期很长。

厂商补丁这条路不太好走,那看看业务上是否可以优化。目前业务使用的统一是短连接,这种策略对低频依赖mc的业务比较友好,而高频的业务则会产生大量的短连接,抓包发现一个MC操作产生的报文数量一半左右都是浪费在握手和挥手,而且有些MC实例每秒建连数高达1.8W,MC实例和业务POD都有亲缘分布的热点问题,当热点流量亲缘集中时会给MC宿主机或业务宿主机带来不小的负担,网卡第一个撑不住,于是产生了波动。

使用短连接有一个背景,使用php-fpm时PHP对于长连接的管理是绑定在php-fpm,业务代码身体无法管理长连接池,而我们几个业务集群峰值可以产生近2W的连接数,云厂商资料显示,维护巨量的长连接,可能会消耗近1G的产品内存,基于以前业务一直很稳定,所以也就没有去太重视这块。(合作云厂商的MC服务是使用redis实现的,做了一层协议转换,一切特性都需要参照redis去理解,且是用户有感,云厂商对用户暴露了部分redis参数,需要业务去调优,MC天然的简洁优势消失殆尽,这也是接入初期产生大量业务不适应的重要根源,特别需要注意的是redis单线程模型、内存管理策略带来的负面影响,如lru时线程繁忙。厂商此paas产品对客户的连接数限制在2W级,后来沟通额外开到4W)

查到原因后于是对症下药,有两个方式解决:

  1. 网卡波动一瞬间报文丢失,但会重传,S报文丢失的时候重传是1秒,其它报文是200ms,业务把timeout改为大于1s,大概率下次重试就成功了
  2. 业务调整为长连接,减少报文量,降压

方案1治标不治本也不符合我的气质,放弃。于是选择方案2,为谨慎起见,进行梯度放量,业务代码里依据pid尾数来控制长连接比例。

一切看上去都那么自然天衣无缝,那就太天真了。

放了一部分量后看监控发现活跃连接数上涨了,挺好,符合预期。再看下新建连接数没有降,业务平均响应时间也微微变差了!,why why why,是监控采集错了吗,不科学啊。一翻折腾确认,监控没有问题,那问题出在哪呢。于是又开始了苦逼的抓包分析  tcpdump -w t.pcap -i eth0 dst 10.13.32.206  然后 tcpdump -r t.pcap  查看

16:26:26.240749 IP 10.242.8.16.37274 > 10.13.33.206.11211: Flags [S], seq 1127458011, win 29200, options [mss 1460,sackOK,TS val 166212987 ecr 0,nop,wscale 9], length 0
16:26:26.240753 IP 10.13.33.206.11211 > 10.242.8.16.37274: Flags [S.], seq 1618708266, ack 1127458012, win 28960, options [mss 1460,sackOK,TS val 3204262586 ecr 166212987,nop,wscale 7], length 0
16:26:26.241093 IP 10.242.8.16.37274 > 10.13.33.206.11211: Flags [.], ack 1, win 58, options [nop,nop,TS val 166212988 ecr 3204262586], length 0
16:26:26.241099 IP 10.242.8.16.37274 > 10.13.33.206.11211: Flags [P.], seq 1:63, ack 1, win 58, options [nop,nop,TS val 166212988 ecr 3204262586], length 62
16:26:26.241101 IP 10.13.33.206.11211 > 10.242.8.16.37274: Flags [.], ack 63, win 227, options [nop,nop,TS val 3204262586 ecr 166212988], length 0
16:26:26.241102 IP 10.242.8.16.37274 > 10.13.33.206.11211: Flags [P.], seq 63:87, ack 1, win 58, options [nop,nop,TS val 166212988 ecr 3204262586], length 24
16:26:26.241104 IP 10.13.33.206.11211 > 10.242.8.16.37274: Flags [.], ack 87, win 227, options [nop,nop,TS val 3204262586 ecr 166212988], length 0
16:26:26.241121 IP 10.13.33.206.11211 > 10.242.8.16.37274: Flags [P.], seq 1:25, ack 87, win 227, options [nop,nop,TS val 3204262586 ecr 166212988], length 24
16:26:26.241446 IP 10.242.8.16.37274 > 10.13.33.206.11211: Flags [.], ack 25, win 58, options [nop,nop,TS val 166212988 ecr 3204262586], length 0
16:26:26.241448 IP 10.242.8.16.37274 > 10.13.33.206.11211: Flags [.], ack 25, win 58, options [nop,nop,TS val 166212988 ecr 3204262586], length 0
#过了段长的时间
16:26:26.891346 IP 10.242.8.16.37274 > 10.13.33.206.11211: Flags [P.], seq 87:111, ack 25, win 58, options [nop,nop,TS val 166213638 ecr 3204262586], length 24
16:26:26.891356 IP 10.242.8.16.37274 > 10.13.33.206.11211: Flags [F.], seq 111, ack 25, win 58, options [nop,nop,TS val 166213638 ecr 3204262586], length 0
16:26:26.891391 IP 10.13.33.206.11211 > 10.242.8.16.37274: Flags [F.], seq 25, ack 112, win 227, options [nop,nop,TS val 3204263236 ecr 166213638], length 0
16:26:26.891697 IP 10.242.8.16.37274 > 10.13.33.206.11211: Flags [.], ack 26, win 58, options [nop,nop,TS val 166213638 ecr 3204263236], length 0

由上面信息看到,每一次建连执行完一次操作后,长连接没有立即关闭,但是过了一小会memcached扩展主动发了个F包,这又是什么黑暗逻辑。总体上来说就是长连接是有了,也存活了一会,但是没有复用就关了,上面的指标变化就都解释通了。

memcached扩展的源码不太看得懂,调整几个php参数试试,结果意外发现,只要以下两个参数都设置为false,问题消失

\Memcached::OPT_BINARY_PROTOCOL
\Memcached::OPT_TCP_NODELAY

果然是memcached主动断开的,于是分析参数利弊后调整一下php调用姿势,把这两个参数设false,发布上线后看到了期望中的效果。但进制改文本后有个副作用就是cpu上涨了。

 

隐约感觉这不是最佳优化姿势,同时本地能复现,发现都是在第二次op操作前发了个F包,然后断开立马又发了S包建连

有线索后,架构林老师快速翻阅C源码,发现有这么一段

彻底解惑了,再改了下php的调用姿势,恢复开启了前面关闭的两个参数

//改造前
$mc = new \Memcached($persistent_id);
$mc->setOptions($options); 
if (!count($mc->getServerList())) {
     $mc->addServers($servers);
}

//改造后
$mc = new \Memcached($persistent_id);
if (!count($mc->getServerList())) {
     $mc->setOptions($options); 
     $mc->addServers($servers);
}

发布代码后发现,新建连接数巨降,CPU大降,活跃连接数大涨。符合预期。

事后结合了memcached 长连接和timeout非预期问题,发现memcached作者搞了不少胡里花俏难懂参数,且文档过于简陋,组合起来产生了非预期结果。而对setOptions()是可以做判断前后是否有变化,而不必每次都断开连接,也算作者偷懒了

 


        

发表评论

电子邮件地址不会被公开。 必填项已用*标注