我正在运行一些基准使用Apache的工作台上运行的Tomcat上的Java应用程序。
说我运行一个testing，如：
ab -c 10 -n 10000 http://localhost:8080/hello/world 它会运行得很好。 如果我遵循它：
ab -c 50 -n 50000 http://localhost:8080/hello/world
它会再次运行良好，但如果我再试一次，它可能会在3500个完成的请求后开始减慢。
我试图debugging这个根本原因需要帮助。
我跑了上面，我有一些未使用的内存的演出，所以内存似乎不是问题。
tomcat6过程确实达到了70-80甚至107％。
似乎重新启动tomcat解决了这个问题，但有时需要重新启动服务器。
这是一个默认的tomcat安装，有200个线程分配给它。
Tomcat日志是空的。
更新
所以我把tcp_tw_recycle / reuse重新设置为1，现在运行netstat显示的计数很低。
在改变tcp_tw_recycle /重用之前，我注意到事情放缓并运行netstat，并且我有32400个tcp TIME_WAIT连接。
所以现在运行基准testing的更新，使用-k开关，我看到更多的吞吐量。 但是，在某些时候，事情再次开始放缓，但重新启动tomcat现在使事情恢复正常。 之前，即使我重新启动tomcat，运行ab的响应时间也会非常慢。 现在改变tcp_tw_recycle / reuse后，重新启动tomcat使事情恢复正常。 运行顶部显示tomcat只有CPU的20％左右，所以现在看来问题是与tomcat，但我怎么能弄清楚什么？
这里可能会有一些事情发生。 上面的命令转换为50个并发连接，每个发出1000个请求。 有一件事要注意的是，如果我记得正确apachebench默认情况下不启用保持活动。 这可能是值得的（通过-k到你的命令上面）。 无论如何，这将是一个真正的世界testing，因为大多数用户代理默认使用keep-alive，就像Tomcat一样。 这应该有助于这个问题，如果我的理论是正确的。
1）我怀疑你的抨击线程池太多请求，因为每一个正在拆除。 这对于那些线程以及系统上的TCP / IP堆栈来说是相当重要的。 这导致我…
2）你可能（好吧，你可能是）用尽了短暂的端口和或击中TIME_WAITsockets。 如果每个请求确实是一个新的，唯一的请求，那么很可能会遇到一个TIME_WAIT情况，在该状态下有成千上万个套接字（请查看netstat -an | grep -ic TIME_WAIT以查看它们的计数你的负载）。 除非您在系统上启用了time_wait_reuse，否则这些套接字将无法再使用。 你使用本地主机的事实只会让事情变得更糟。
有关设置time_wait重用的更多信息，请看这里 。 还要注意，这个线程正确地指出，在time_wait的上下文中设置fin_wait超时是不正确的，所以要避免这一点。 在TIME_WAIT的背景下发出fin_wait是错误的，并不会帮助你。
所以看看，并可能调整tcp_tw_recycle /专门重用。 这些将帮助您通过testing，并保持活力。