我正在使用apache bench为tomcat上运行的
java应用程序运行一些基准测试.
说我运行一个测试:
ab -c 10 -n 10000 http://localhost:8080/hello/world
它运行得很好.如果我遵循它:
ab -c 50 -n 50000 http://localhost:8080/hello/world
它再次运行正常,但如果我再试一次,它可能会在3500个完成请求后开始减速.
我在尝试调试其根本原因方面需要帮助.
我跑了顶,我有一些未使用的内存,所以内存似乎不是问题.
tomcat6进程确实达到70-80甚至107%.
似乎重启tomcat解决了这个问题,但有时需要重启服务器.
这是在默认的tomcat安装上,分配了200个线程.
Tomcat日志为空.
更新
所以我将tcp_tw_recycle / reuse都更改为1,并且运行netstat现在显示的计数非常低.
在更改tcp_tw_recycle / reuse之前,我注意到事情变慢并运行netstat并且我有32400个tcp TIME_WAIT连接.
所以现在运行基准测试的更新,使用-k开关我看到了更多的吞吐量.
但是,在某些时候事情再次开始减速,但重新启动tomcat现在让事情恢复正常.以前,即使我重新启动tomcat,运行ab的响应时间也会非常慢.现在在更改tcp_tw_recycle / reuse之后,重启tomcat会使事情恢复正常.运行顶部显示tomcat只占cpu的20%左右,所以现在问题似乎是tomcat,但我怎么能搞清楚什么?
@H_
301_33@
这里可能会有一些事情发生.上面的命令转换为50个并发连接,每个连接发出1000个请求.这里要注意的一件事是,如果我没记错,apachebench默认情况下不启用keep alive.可能值得
添加(将-k传递给上面的命令).无论如何,这将是一个真实世界的测试,因为大多数
用户代理都使用keep-alive,默认情况下也是Tomcat.如果下面的理论是正确的,这应该有助于
解决问题.
1)我怀疑你抨击那个线程池有太多请求,因为每个人都在崩溃.对于那些线程以及系统上的TCP / IP堆栈来说,这是一个非常大的打击.这导致我……
2)你可能(好吧,你可能正在)用完短暂的端口和/或命中TIME_WAIT套接字.如果每个请求确实是一个新的,唯一的请求,那么你很可能会遇到在该状态下有数千个套接字的TIME_WAIT情况(请查看netstat -an | grep -ic TIME_WAIT以获取它们的计数)你的负担).除非您在系统上启用了time_wait_reuse,否则这些套接字将无法重复使用.您使用localhost的事实只会使情况变得更糟.
有关设置time_wait重用的更多信息,请查看here.另请注意,此线程正确指出在time_wait的上下文中设置fin_wait超时是不正确的,因此请避免这样做.在TIME_WAIT的上下文中发痒fin_wait是错误的,对你没有帮助.
因此,请查看并特别调整tcp_tw_recycle / reuse.这些将帮助您完成测试,并保持活力.