JMeter压测AWS ALB：低资源使用率下线程数达16450时出错

针对16400线程正常、16450线程报错，且EC2资源（CPU、内存、入站网络）低位、扩容EC2无效的情况，核心瓶颈大概率不在EC2实例本身，而是中间层或客户端/协议层面的限制，以下是具体排查点：

• ALB配额/限流触发
  AWS ALB有默认的并发连接数、每秒请求数（RPS）等软配额，即便EC2资源空闲，当请求量触及ALB的配额阈值时，会直接返回5XX错误或拒绝连接。排查CloudWatch中的ALB指标：

  • HTTPCode_ELB_5XX_Count：统计ALB返回的5XX错误数
  • SurgeQueueLength：ALB待处理请求队列长度，若持续增长说明ALB无法及时转发请求
  • SpilloverCount：因队列满被丢弃的请求数，若大于0则明确触发了ALB限流

• JMeter客户端本地资源瓶颈
  不要仅关注压测机的CPU/内存，需重点排查临时端口耗尽和JMeter自身连接限制：

  • 执行netstat -an | grep TIME_WAIT | wc -l查看TIME_WAIT状态的连接数，若接近系统临时端口范围（Linux默认约28k），会导致无法新建连接。可调整内核参数net.ipv4.tcp_tw_reuse=1、net.ipv4.tcp_tw_recycle=1（注意部分系统兼容性）
  • 检查JMeter的httpclient4.maxconnections配置（默认200），需将其调整为不低于线程数，否则JMeter客户端自身会限制并发连接数

• EC2实例连接跟踪表耗尽
  EC2内核的net.netfilter.nf_conntrack_max参数控制TCP连接跟踪的最大数量，若并发连接数超过该值，内核会拒绝新连接，此时EC2资源可能仍处于低位：

  • 执行sysctl net.netfilter.nf_conntrack_max查看当前阈值
  • 执行cat /proc/net/nf_conntrack | wc -l查看已使用的连接跟踪数，若接近阈值则需调大该参数

• 前端Web服务器的连接限制
  即便React是静态资源，承载前端的Web服务器（如Nginx、Apache）有自身的并发连接限制：

  • 查看Web服务器日志，若存在too many open files或连接拒绝的日志，需调整服务器的并发连接参数（如Nginx的worker_connections）
  • 调整EC2实例的ulimit值，放开进程可打开的文件句柄数（默认1024，远低于16k+的并发需求）

• TCP协议层面的SYN队列溢出
  当大量并发连接请求涌入时，EC2的SYN队列（net.ipv4.tcp_max_syn_backlog）若容量不足，会丢弃SYN包导致连接失败：

  • 执行netstat -s | grep SYN查看SYN包丢弃统计，若存在“dropped SYN packets”则需调大该参数

内容的提问来源于stack exchange，提问作者Michael James