说我运行一个测试：
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,但我怎么能搞清楚什么？
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.这些将帮助您完成测试,并保持活力.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
