记一次高并发压测过程中遇到的坑

背景

测试在用jmeter进行压力测试，在并发量高的时候，先后出现的一系列问题。这里总结一下做个回顾
环境：
主机A：window 版本的 nginx
主机B：
Linux VMware2台虚拟机：
虚拟机A：部署项目服务
虚拟机B：Oracle，redis
流程：nginx部署单结点服务在虚拟机A上面，通过jmeter进行压力测试。

排查问题思路：

1.检查nginx错误日志（排查请求是否正常）
2.检查后台日志（排查服务是否正常）
3.根据错误提示解决问题
4.监控后台cpu（防止压测系统崩了未察觉）

问题一：nginx突破1024限制

在高并发的时候，遇到的第一个问题：
请求一部分失败，一部分成功。
1.jmeter报错500
2.nginx error日志报错：
nignx：maximum number of descriptors supported by select() is 1024 while connecting to upstream
解决方式：

查阅记录的另一篇博客：
nginx突破1024限制

问题二：connect refuse

问题现象：报连接超时，考虑是否连接满了。
1.检查yml配置文件druid连接池max-active（最大连接数）配置的好多
2.检查Oracle连接数
show parameter processes; 查询数据库允许的最大连接数：
select count(*) from v$process; 查询数据库当前进程的连接数

最后发现确实连接数设置得太低了，增大连接数即可。

详情参阅：查询数据库当前连接数(session)，进程数，修改最大连接数等操作

问题三：upstream timed out 10060

现象：当并发量设置很高的时候，接口请求短时间内卡死，一直请求连接中。经过较长时间后返回响应结果，之后的请求全失败。
尝试方式一减少反向代理连接时间：
proxy_connect_timeout 1;
proxy_send_timeout 30;
proxy_read_timeout 60;

尝试方式二.修改fastcgi配置项
fastcgi_connect_timeout：nginx与后端fastcgi server连接超时时间，默认60s
fastcgi_send_timeout： nginx向后端传送请求超时时间（指已完成两次握手后向fastcgi传送请求超时时间），默认60s
fastcgi_read_timeout: nginx接受后端fastcgi响应请求超时时间 （指已完成两次握手后nginx接受fastcgi响应请求超时时间）,默认60s
fastcgi_buffer_size: nginx读取fastcgi响应第一部分需要用多大的缓冲区
fastcgi_buffers: nginx需要用多大的缓冲区缓冲fastcgi的应答请求.fastcgi_buffers 15 128k;指的15个128k大小的缓冲区

详细参阅：nginx fastcgi配置

  server {
    listen 80;
    server_name 127.0.0.1;

    # 时间戳系统
    location ^~ /timestamp/ts {
      proxy_pass http://mcs-tsa;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection $connection_upgrade;
	  # proxy_connect_timeout 300; 
	  # proxy_send_timeout 300; 
	  # proxy_read_timeout 300; 
	  # fastcgi_connect_timeout 1800;
	  # fastcgi_send_timeout 1800; 
	  # fastcgi_read_timeout 1800; 
	  # fastcgi_buffers 15 128k;
    }
  }

尝试如上的方式后，虽然jmeter跑接口可以较长一点时间请求正常，但是多经过时间又会出现这个问题。

问题四：Linux服务器大量端口TIME_WAIT

经过上面的尝试后问题依然得不到解决，后面查看服务器端口，发现大量端口TIME_WAIT，应该就是这个原因导致的。端口不停的被请求，端口释放的速度低于端口占用的速度，并发高的情况很快就占满了65535个端口。

解决方式一：调整内核参数（未尝试）
vi /etc/sysctl.conf

编辑文件，加入以下内容：

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_tw_recycle = 1

net.ipv4.tcp_fin_timeout = 30

然后执行/sbin/sysctl -p让参数生效。

net.ipv4.tcp_syncookies = 1表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；

net.ipv4.tcp_tw_reuse = 1表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；

net.ipv4.tcp_tw_recycle = 1表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

net.ipv4.tcp_fin_timeout修改系統默认的TIMEOUT时间

修改之后，再用命令查看TIME_WAIT连接数
netstat -ae|grep “TIME_WAIT” |wc –l

详情参阅：linux 大量的TIME_WAIT解决办法

尝试方法二：修改windows注册表配合jmeter测试

后续跟测试沟通，说是jmeter要修改注册表配合测试

windows命令行输入：regedit 打开注册表

新增4个参数：
MaxUserPort: 最大用户端口数

TCPTimedWaitDelay: TCP等待延迟时间(确保端口释放)

尝试办法三：修改jmeter请求方式

去掉这个选项（不勾选）：same user on each iteration

最后访问正常。

疑问：same user on each iteration意思是同一个用户在访问，勾上并不能代表真正意义上的多线程访问。这个问题到线上感觉依然会有问题。

我这里没有尝试调整内核参数。调整以后应该会有很好的改善。

总结

这是第一次经历正式的压测。期间出了很多问题，也花了大量的时间解决问题。

原因在于：
1.nginx经验不足，调整参数不熟悉
2.jmter经验不足，跟测试沟通尚晚
3.以前没有一个处理高并发的意识。druid连接池和数据库的连接数都比较低，没有维护

总之：革命尚未成功，同志仍需努力。。。

学习博客：
Linux下高并发socket最大连接数所受的各种限制(详解)
jmeter 压测常见的几种报错
Jmeter测试会出现端口占用情况
Tcp连接出现大量ESTABLISHED连接解决方法