如何解决找到连接超时的原因并在对Kubernetes集群进行JMeter分布式测试中解决它的好主意
我创建了一个Kubernetes集群（两个节点），并在其中部署了两个Nginx应用程序和一个Redis服务器。
[admin@k8snode1 ~]$ kubectl get pod -owide && kubectl get service -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
my-nginx-585cd7685d-69gqz 1/1 Running 10 2d3h 192.168.185.245 k8snode2 <none> <none>
my-nginx-585cd7685d-7zb9d 1/1 Running 10 2d3h 192.168.249.36 k8snode1 <none> <none>
redis-master-7cc9b97ff-pdrmt 1/1 Running 1 14d 192.168.185.237 k8snode2 <none> <none>
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 23d <none>
my-nginx NodePort 10.97.143.231 <none> 80:30080/TCP,443:30443/TCP 14d app=my-nginx
redis NodePort 10.105.99.156 <none> 6379:30826/TCP 14d app=redis
但是，当我使用Apache JMeter进行负载测试时（在一台Windows 10计算机上，模拟800个并发用户，仅一次控制器下的1个OAuth2.0 HTTPS采样器和无限循环控制器下的13个其他HTTPS采样器） ）。
只有800个用户，我的应用程序在第一时间就崩溃了。查看结果错误树中有太多错误。
- HTTP 401（未经授权）响应
- java.net.SocketTimeoutException（连接超时）
- readResponse：java.net.SocketException：套接字已关闭
首先，我关注第一个问题，即HTTP 401（未经授权）响应。我发现原因是通过以下nsenter命令而不是在两个节点上直接执行netstat -anolept或ss -no state time-wait来进行大量Redis TIME_WAIT连接（15000 +）
sudo nsenter -t $(docker inspect -f {{.State.Pid}} $(docker container ls -f label=io.kubernetes.container.name=my-nginx --format={{.Names}})) -n netstat -anolept | awk 'NR>2{print $6}' | sort | uniq -c | sort -r
[admin@k8snode1 ~]$ ulimit -a
core file size (blocks,-c) 0
data seg size (kbytes,-d) unlimited
scheduling priority (-e) 0
file size (blocks,-f) unlimited
pending signals (-i) 23086
max locked memory (kbytes,-l) 64
max memory size (kbytes,-m) unlimited
open files (-n) 1024
pipe size (512 bytes,-p) 8
POSIX message queues (bytes,-q) 819200
real-time priority (-r) 0
stack size (kbytes,-s) 8192
cpu time (seconds,-t) unlimited
max user processes (-u) 4096
virtual memory (kbytes,-v) unlimited
file locks (-x) unlimited
[admin@k8snode1 ~]$ cat /proc/sys/net/ipv4/ip_local_port_range /proc/sys/net/ipv4/tcp_fin_timeout /proc/sys/net/ipv4/tcp_tw_reuse /proc/sys/net/ipv4/tcp_tw_recycle
32768 60999 # 60999 - 32768 = 28231
60
0
0
我没有使用连接池更改像nginx上游这样的代码，但是我在两个节点上更改了/proc/sys/net/ipv4/tcp_tw_recycle。结果，这些问题得到了暂时解决。
然后，我添加了一台额外的Windows 10计算机来进行分布式（远程）测试。不幸的是，前两个错误再现了，nsenter + netstat的结果中只有100〜500次TIME_WAIT。此后，我添加了一个JSR223断言来记录OAuth2响应，因为在视图结果错误树中找不到OAuth2.0 HTTPS采样器的任何错误（我不知道为什么）。此外，根据客户端侧的jmeter-server.log和服务器侧的日志，我发现nginx已为所有OAuth2请求成功将令牌保存在Redis中，但是在客户端上有3〜5个用户连接（共1600个）超时JMeter客户端。
现在，我发现了另一个命令conntrack。
# Show the connection tracking table in /proc/net/ip_conntrack format
[admin@k8snode1 ~]$ sudo conntrack -L > "sudo conntrack -L $(TZ=Asia/Shanghai date '+%F %H%M%S.%N %:z (%Z)').txt"
conntrack v1.4.4 (conntrack-tools): 150808 flow entries have been shown.
[admin@k8snode1 ~]$ netstat -anolept | awk 'NR>2{print $6}' | sort | uniq -c | sort -r
(Not all processes could be identified,non-owned process info
will not be shown,you would have to be root to see it all.)
29 LISTEN
204 ESTABLISHED
[admin@k8snode1 ~]$ awk '/^tcp/{print $4}' 'sudo conntrack -L.txt' | sort | uniq -c | sort -r
94383 TIME_WAIT
1959 SYN_SENT
514 ESTABLISHED
42 CLOSE
5 FIN_WAIT
1 CLOSE_WAIT
[admin@k8snode1 ~]$ awk '/^tcp/{print $6}' 'sudo conntrack -L.txt' | sort | uniq -c | sort -r
82131 dst=10.23.57.12
14598 dst=10.105.99.156
122 dst=127.0.0.1
24 dst=192.168.249.28
24 dst=192.168.249.27
4 dst=10.96.0.1
1 dst=192.168.185.234
[admin@k8snode1 ~]$ mount -t cgroup
根据上面给出的统计数据，一个节点上的tcp连接数量大大超过了28231（= 60999-32768），甚至是65535（= 2 ^ 16-1），真的合理吗？
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。