记一次Jmeter高并发，问题定位、系统优化过程

先说结论

 现象：JMeter 通过模拟大量的源IP（1300个IP）发送到Tomcat服务器端，出现不少接口响应超时 connect timeout。

原因：Linux系统对于Arp表的数目有上限：1024，大量并发请求产生时，无法生成ARP表象，导致超时

修改点：

1、vim /etc/sysctl.conf   添加  

net.ipv4.neigh.default.gc_thresh1 = 2048

net.ipv4.neigh.default.gc_thresh2 = 4096

net.ipv4.neigh.default.gc_thresh3 = 10240

------------------------------------------------------------------------------------------------------------------------------

问题背景：

Linux系统下，部署了2套Tomcat，监听不同的端口，使用同一个mysql及redis。模拟1000个IP给其中一个servlet打接口，另外一个模拟300接口

 

 

基于问题现象：

1、首先查看资源使用情况，观察Top ：

发现两个CPU核，几乎都没有占满：

首先排查线程使用情况，因为当时tomcat配置了线程池和名称，通过jstack拉取线程数据，查看当前的线程执行情况，并没有出现线程阻塞，线程死锁等情况，这个和CPU占用不满情况的情况是一致的

 

2、查看系统的内存使用情况：

怀疑点在于，系统内存较高，导致系统内存不足，影响IO的内存占用。通过free -m 和jmap，mmap拉取内存信息，并没有发现内存的异常。

 

3、怀疑是TCP 连接有限制 ，通过netstat -anp 查看到有大量的Time_wait，查看网上说明都是在于调整系统文件句柄数，但是对Time_wait过多的情况并没有太多说明，优化系统参数

修改了上述的5000之后，确实数量Time_wait降到5000了，但问题现象还出现，线索就此中断。

 

后面和网管详细讨论，描述了实际模拟的场景，突然提到一个这么多IP从哪里来的，实际组网如何，我这边的IP是怎么识别到并到我的设备上去了，才明白了我的设备与模拟设备是直连的关系，中间并没有交换机，因此所有的主机报文的ARP信息都需要在我的设备上存储的，后来搜索之后才知道Linux系统默认的arp表数量为1024.

-------------------------------------------------------------------------------------------

回顾一下之前的定位分析，中间其实漏了很多其他的问题定界排除动作，从JAVA本身排除，到数据库/缓存连接排除，到Tomcat排除，到CPU内存排除，再到网络IO排除。最终才找到了问题所在，有些细节已经回顾不出来了，所以，博客还是尽早更新的好。

另外，对数字的敏感性很重要，当时现象是2个Tomcat，一个跑1000，一个跑300，单独跑都没问题，一起跑就有问题，所以当时怀疑有一个瓶颈点，在于数字1024，基于这点才快速的反应出是ARP数目的限制