zoukankan      html  css  js  c++  java
  • Tomcat connectionTimeout问题定位处理

    问题现象

    在某个时刻,后端收到了平时4-6倍的请求(保密起见,略去产品和事件),在10分钟后居然没有请求可以接进来

    问题原因

    经过分析,首先,是后端服务器的线程池满了,线程池满的原因:
    1.server.xml中maxThread=512,导致超过512的之后的请求只能排队,等待有线程释放后,才能被处理;
    2.connectionTimeout配置为10000,这个配置导致建立一个socket连接后,如果一直没有收到客户端的FIN,也没有数据过来,那么此连接也必须等到10s后,才能被超时释放,巧了,现网的客户端真的不会发FIN包过来,那一直陪它耗够10秒,和1一起,处理的512个线程只能等待10s后,超时释放才能处理后面排队的请求,所以浪涌一来,分分钟就满了。

    接下来是怎么接不进来的呢?

    部分用户忍不了了,发了个登出请求,依然在特慢的排队,部分进入了队列的客户端加上前面时间一共等了几秒都没响应,客户端就发了个FIN过来,说要不咱主动断开算了,后端收到请求变为CLOSE_WAIT状态,说你等我会,处理点事,巧了,用户这几秒也受不了了,整个重启客户端,客户端ip再来就变了,结果后端处理好后的第三次握手本该通知"我处理好了,你断吧"的请求发不过去,好死不死,后台还配的重发15次,重发15次需要大概20~30分钟左右,啊哦,于是这条请求一直占着线程20多分钟,这样的请求多点,线程就一直占着,于是别的请求就一直就接不进来咯

    问题解决

    1.修改maxThread=1024,提高一倍的线程数

    2.修改connectionTimeout=2000,没数据了之后2秒就断,别等这么久(keepAlivetimeout是请求处理完了之后等多久关闭连接,connectionTimeout是本条连接等多久没数据关连接)

    3.修改/proc/sys/net/ipv4/目录下的tcp_retries2文件为4,别重发15次了,一般也用不了这么多

  • 相关阅读:
    tile38 复制配置
    The Guardian’s Migration from MongoDB to PostgreSQL on Amazon RDS
    tile38 一款开源的geo 数据库
    sqler sql 转rest api 的docker 镜像构建(续)使用源码编译
    sqler sql 转rest api javascript 试用
    sqler sql 转rest api redis 接口使用
    sqler sql 转rest api 的docker image
    sqler sql 转rest api 的工具试用
    apache geode 试用
    benthos v1 的一些新功能
  • 原文地址:https://www.cnblogs.com/moonandstar08/p/7679281.html
Copyright © 2011-2022 走看看