奇怪的Tomcat中断,可能与maxConnections有关

Question

在我的公司,我们今天遇到了严重的问题:我们的生产服务器出现故障.大多数通过浏览器访问我们软件的人无法获得连接,但是已经使用该软件的人能够继续使用它.甚至我们的热备用服务器也无法与生产服务器通信,它使用HTTP进行通信,甚至无法访问更广泛的互联网.服务器可以通过ping和ssh访问的整个时间,实际上是非常负载 - 它通常以5%的CPU负载运行,此时甚至更低.我们几乎没有磁盘i/o.

问题开始几天后,我们有了一个新的变化:端口443(HTTPS)正在响应,但端口80停止响应.服务器负载非常低.重启tomcat后,端口80立即开始响应.

我们使用tomcat7,maxThreads ="200",并使用maxConnections = 10000.我们从主内存中提供所有数据,因此每个HTTP请求都很快完成,但是我们有大量用户进行非常简单的交互(这是高中科目选择).但我们似乎不太可能拥有10,000个用户,同时他们的浏览器在我们的页面上打开.

我的问题有几个部分:

• "maxConnections"参数可能是导致我们困境的原因吗？
• 有没有理由不将"maxConnections"设置为可笑的高值,例如100,000？(这样做的成本是多少？)
• 一旦命中"maxConnections"消息,tomcat会在任何地方输出警告消息吗？(我们没有注意到任何事情).
• 我们可能会遇到操作系统限制吗？我们使用的是CentOS 6.4(Linux),"ulimit -f"表示"无限制".(防火墙是否了解Tcp/Ip连接的概念？其他地方是否存在限制？)
• 当tomcat达到"maxConnections"限制时会发生什么？它是否尝试关闭一些不活动的连接？如果没有,为什么不呢？我不喜欢这样的想法,即我们的服务器可以被拥有浏览器的人赎金,发送保持活动以保持连接打开.

但主要问题是,"我们如何修复我们的服务器？"

按照Stefan和Sharpy的要求提供更多信息:

• 我们的客户直接与此服务器通信
• 在某些情况下,TCP连接立即被拒绝,在其他情况下超时
• 即使将我的浏览器连接到网络中的服务器,或者与热备用服务器(也在同一网络中)无法进行通常通过HTTP发生的数据库复制消息,问题就很明显了.
• IPTables - 是的,IPTables6 - 我不这么认为.无论如何,当我在注意到问题后进行测试时,我的浏览器和服务器之间没有任何内容.

更多信息:当我们意识到我们使用的是BIO的默认Tomcat7设置(每个连接有一个线程,并且我们有maxThreads = 200)时,看起来我们已经解决了问题.实际上'netstat -an'显示了大约297个连接,它们匹配200 + 100的队列.所以我们将其更改为NIO并重新启动了tomcat.不幸的是,第二天发生了同样的问题.我们可能错误配置了server.xml.

来自catalina.out的server.xml和摘录可在此处获取:https://www.dropbox.com/sh/sxgd0fbzyvuldy7/AACZWoBKXNKfXjsSmkgkVgW_a？dl = 0

更多信息:我做了负载测试.我可以从我的开发笔记本电脑创建500个连接,并且每个都进行3次HTTP GET,没有任何问题.除非我的负载测试无效(Java类也在上面的链接中).

Answer 1

简短的回答：

• 使用 NIO 连接器代替默认的 BIO 连接器
• 将“maxConnections”设置为合适的值，例如 10,000
• 鼓励用户使用HTTPS，这样中间代理服务器就无法将100个页面请求变成100个tcp连接。
• 检查由于死锁问题而挂起的线程，例如使用堆栈转储（kill -3）
• （如果适用，并且您尚未执行此操作，请编写客户端应用程序以使用一个连接来处理多个页面请求）。

长答案：

我们使用 BIO 连接器而不是 NIO 连接器。两者的区别在于BIO是“每个连接一个线程”而NIO是“一个线程可以服务多个连接”。因此，如果我们不增加“maxThreads”，那么增加“maxConnections”是无关紧要的，我们没有增加“maxThreads”，因为我们不理解BIO/NIO的区别。

要将其更改为 NIO，请将其放入 server.xml 的元素中：protocol="org.apache.coyote.http11.Http11NioProtocol"

根据我的阅读，使用 BIO 没有任何好处，所以我不知道为什么它是默认的。我们使用它只是因为它是默认设置，并且我们假设默认设置是合理的，并且我们不想成为现在这样的 tomcat 调优专家。

然而：即使在进行此更改之后，我们也遇到了类似的情况：在同一天，即使 HTTP 正在工作，HTTPS 也变得无响应，然后不久又发生了相反的情况。这有点令人沮丧。我们检查了“catalina.out”，发现实际上正在使用 NIO 连接器，而且确实如此。因此我们开始了对“netstat”和wireshark的长期分析。我们注意到连接数量在某些时期出现高峰 - 在一种情况下，当基线约为 70 时，连接数量高达 900 个。当我们在主生产服务器和每个客户安装的“设备”之间同步数据库时，就会出现这些高峰。站点（学校）。我们进行的同步越多，造成的中断就越多，这导致我们以螺旋式下降的方式进行更多的同步。

似乎发生的情况是，新南威尔士州教育部代理服务器将我们的数据库同步流量拆分为多个连接，以便 1000 个页面请求变成 1000 个连接，而且它们直到 TCP 4 分钟超时才正确关闭。代理服务器只能执行此操作，因为我们使用的是 HTTP。他们这样做的原因大概是负载平衡——他们认为通过将页面请求分散到 4 台服务器上，他们可以获得更好的负载平衡。当我们切换到 HTTPS 时，他们无法执行此操作，只能使用一个连接。这样这个特殊问题就被消除了——我们不再看到连接数量的激增。

人们建议增加“maxThreads”。事实上，这会有所改善，但这不是“正确”的解决方案 - 我们有默认值 200，但在任何给定时间，几乎没有任何一个在做任何事情，事实上几乎没有任何一个被分配给页面请求。