关于dubbox部分rest接口超时问题研究

 

业务高峰期部分rest接口超时有一段时间了,之前一直怀疑是kafka、nginx、log4j、网络等原因并进行优化,一直没有太大改观。我们生产共有四台nginx反向代理网关,运维在某台nginx中通过日志grep看到,高峰期   nginx反向代理到后端某台tomcat,每秒达到100+,4台nginx则为400+,已超过tomcat设置的并发连接数和完全连接队列的大小(200+100=300)。前两天运维说把tomcat线程数调大到600之后(原来是200),超时问题就没有再出现了。

 

事后考虑原因分析如下:

tomcat配置中有一个参数叫acceptCount,这个参数在tomcat中指server端监听端口的完全连接队列的socket上限(backlog)。这个值在dubbox中是不能设置的,默认100。

另一个参数叫threadCount,这个参数指tomcat工作线程池大小。tomcat线程池每次从队列头部取线程去处理请求,请求完结束后再放到队列尾部,也就是说前后两次请求处理不会用同一个线程。如下:


 

换句话说,之前threadCount=200、acceptCount=100时,tomcat能接受的最大并发数就是200,如果并发数>200时,只会有额外的100个并发请求会在完全连接队列中排队,其他并发请求则根本进入不了完全连接队列中,会被服务端拒绝处理(详见注1)。还有三种情况:

1、半连接队列满了:详见注2

2、在完全连接队列中超时:出现这种情况,主要因为接口处理响应慢,导致tomcat工作线程池没有空闲的线程处理完全连接队列中的请求,完全连接队列中的请求在到达超时时间(20s)时,被nginx主动关闭了tcp连接(nginx日志中http ressponse code:504)。有一点要注意,已经进入完全连接队列中的请求,最终会被tomcat处理,只不过此时连接已经断开,nginx不会收到tomcat的响应。

3、接口处理超时:出现这种情况,说明请求已经在tomcat的工作线程中处理了,确实由于接口处理响应慢,而最终被nginx主动关闭了tcp连接。 

 

结论:

治标的方法是增加tomcat工作线程池(threadCount)的数量,而治本的方法还是要提高接口的响应速度(rt:response time)。试想如果我们的所有接口都能控制在100ms之内,tomcat工作线程池设置为200,单机也能承受峰值2000(200 / 0.1)的并发量请求量(当然mem和cpu不能太差)。

 

 

注1:当accept队列满了之后,即使client继续向server发送ACK的包,也会不被响应,此时ListenOverflows+1,同时server通过/proc/sys/net/ipv4/tcp_abort_on_overflow来决定如何返回,0表示直接丢弃该ACK,1表示发送RST通知client;相应的,client则会分别返回read timeout 或者 connection reset by peer

 注2:对于SYN半连接队列的大小是由(/proc/sys/net/ipv4/tcp_max_syn_backlog)这个内核参数控制的,有些内核似乎也受listen的backlog参数影响,取得是两个值的最小值。当这个队列满了,不开启syncookies的时候,Server会丢弃新来的SYN包,而Client端在多次重发SYN包得不到响应而返回(connection time out)错误。但是,当Server端开启了syncookies=1,那么SYN半连接队列就没有逻辑上的最大值了,并且/proc/sys/net/ipv4/tcp_max_syn_backlog设置的值也会被忽略。

 

 最后再附录一张tcp连接建立 和 半连接队列和完全连接队列的图,很经典!



 

 

参考链接:

tcp的半连接与完全连接队列

https://segmentfault.com/a/1190000008224853

tomcat的acceptCount与maxConnections

https://segmentfault.com/a/1190000008064162

 

展开阅读全文

没有更多推荐了,返回首页