一 背景
购物车依赖推荐的dubbo接口,推荐服务每天凌晨3点会批量下线推荐dubbo服务,全量更新商品,更新完以后在执行上线操作,每天凌晨3点10分左右,购物车工程都会出现5000左右的connection timeout error。正常依赖的dubbo服务工程在启动的时候,消费端会经常出现connection timeout error。
二 问题排查
遇到问题之后,sa,中间件开发,推荐开发,购物车开发等拉群排查问题,分析影响面。
dubbo源码分析
总结:推荐服务上线之后,消费端收到zookeeper通知,会主动拉取推荐dubbo服务的URL信息。消费端拿到URL信息后,如果connections不配置,则共享连接,否则每服务每连接,然后将该服务URL和clinets列表封装成一个DubboInvoker对象。如果connection timeout下次会重试。
哨兵监控分析
我们发现在connection timeout error出现的时候,推荐服务器TcpExtListenOverflows,TcpExtListenDrops指标异常。
TcpExtListenDrops(监听队列连接丢弃数)和 TcpExtListenOverflows(监听队列连接溢出数):
- ListenOverflows:3次握手之后进入Accept Queue,如果Accept Queue满了,队列溢出连接就会丢弃,TcpExtListenOverflows值增加1;
- ListenDrops:包含上面的情况,也就是说当出现ListenOverflows时,它也会增加1;除此之外,当内存不够无法为新的连接分配socket相关的数据结构时,也会增加1,当然还有别的异常情况下会增加1。
Accept Queue 的队列长度是由程序的backlog和系统参数net.core.somaxconn共同设置,当backlog的值大于系统设置的net.core.somaxconn时则取net.core.somaxconn的值,否则取程序设置的backlog值。
总结:net.core.somaxconn默认值是128,dubbo backlog目前1024, min(net.core.somaxconn, backlog) = 128。推荐一个服务的提供者的消费者就由1600多,推荐服务一上线,消费者都是第一时间去建立连接,导致Accept Queue溢出。
参考:
SYN packet handling in the wild
三 解决问题
问题已经分析完成,解决的思路:
- 增加云主机net.core.somaxconn值和dubbo backlog值。
- 修改dubbo源码,服务提供者一上线,消费者延迟随机时间之后去建立连接。
目前所有云主机同步参数net.core.somaxconn调整到2048,dubbo backlog默认值还是1024,需要压测确定具体值,connection timeout error已经由原先的6000降低到200,connection timeout之后会重试连接,不会影响业务功能。
已有 0 人发表留言,猛击->> 这里<<-参与讨论
ITeye推荐