Grails +雄猫+ Ubuntu 问题:CLOSE_WAIT 连接
当使用标准组件运行一个简单的 Grails 应用程序时,我在生产中遇到了一个非常奇怪的稳定性问题。
正常运行一段时间后,处于状态 CLOSE_WAIT
的 Tomcat (jsvc
) TCP 连接数量会增加,直到 Tomcat 达到其线程上限(最大线程数 (N))为连接器创建
),之后 Tomcat 就会停止运行。
通常,这表明应用程序包含未正确关闭其 TCP 连接的代码。然而,我在这个应用程序中的 Grails 代码确实非常简单,并且不会自行启动任何 TCP 连接,因此我想不出我的代码可能导致 CLOSE_WAIT
问题的任何场景。
此外,堆栈中的所有组件都是标准的东西,我认为没有错误;我在 Ubuntu 9.1 中捆绑的标准 Tomcat 6 下运行 Grails 1.2.1 (apt-get install tomcat6
)。
- 这是一个已知问题吗?
- 您将如何解决该问题?
I have encountered a really bizarre stability problem in production when running a trivial Grails application using standard components.
After some time of normal operation the number of Tomcat (jsvc
) TCP connections in state CLOSE_WAIT
increases until Tomcat hits its thread ceiling (Maximum number of threads (N) created for connector
), after which Tomcat grinds to a halt.
Normally this would indicate that the application contains code that does not properly close its TCP connections. However, my Grails code in this application is really really trival and does not initiate any TCP connections on its own, so I can't think of any scenario where my code could cause the CLOSE_WAIT
problem.
Furthermore, all the components in the stack are all standard stuff that I'd assume to be bug free; I'm running Grails 1.2.1 under the standard Tomcat 6 that comes bundled in Ubuntu 9.1 (apt-get install tomcat6
).
- Is this a known problem?
- How would you go about trouble-shooting it?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
Filip Hanik 的“Tomcat 专家系列:性能调优”(2009)< /a> 是 Tomcat 中性能调整和稳定性改进设置的优秀指南。
我发现指南中的以下提示是相关的:
在此处描述的切换到 NIO 连接器的情况下,增加 maxThreads 并降低 connectionTimeout 可能会成功。
Filip Hanik's "Tomcat Expert Series: Performance Tuning" (2009) is an excellent guide to performance tuning and stability improving settings in Tomcat.
I found the following tips in the guide to be relevant:
In the case described here switching to a NIO connector, increasing maxThreads and lowering connectionTimeout might do the trick.
该场景中是否包含防火墙?这些往往会在一段时间后断开空闲的 TCP/IP 连接,从而产生您所看到的行为。
Is there a firewall included in the scenario? These tend to drop idle TCP/IP connection after a while giving the behaviour you see.