[alibaba/tengine]开启reuse_port后大压力下出现连接超时的现象

4

hi, 新内核+tengine的时候, 均衡软中断了吗?

taoyuanyuan

9

已经做了网卡多队列的CPU亲缘性绑定 + RPS 软中断分多核。而且已经故意避开首核的使用：

#!/bin/bash
cat /proc/irq/{63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80}/smp_affinity
echo 400   > /proc/irq/63/smp_affinity
echo 2     > /proc/irq/64/smp_affinity
echo 4     > /proc/irq/65/smp_affinity
echo 8     > /proc/irq/66/smp_affinity
echo 10    > /proc/irq/67/smp_affinity
echo 20    > /proc/irq/68/smp_affinity
echo 40    > /proc/irq/69/smp_affinity
echo 80    > /proc/irq/70/smp_affinity
echo 100   > /proc/irq/71/smp_affinity
echo 200   > /proc/irq/72/smp_affinity
echo 400   > /proc/irq/73/smp_affinity
echo 800   > /proc/irq/74/smp_affinity
echo 10    > /proc/irq/75/smp_affinity
echo 20    > /proc/irq/76/smp_affinity
echo 40    > /proc/irq/77/smp_affinity
echo 80    > /proc/irq/78/smp_affinity
echo 100   > /proc/irq/79/smp_affinity
echo 200   > /proc/irq/80/smp_affinity
echo '--------'
cat /proc/irq/{63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80}/smp_affinity
# Enable RPS (Receive Packet Steering)
rfc=4096
cc=$(grep -c processor /proc/cpuinfo)
rsfe=$(echo $cc*$rfc | bc)
sysctl -w net.core.rps_sock_flow_entries=$rsfe
for fileRps in $(ls /sys/class/net/eth*/queues/rx-*/rps_cpus)
do
    echo ffe > $fileRps
done

for fileRfc in $(ls /sys/class/net/eth*/queues/rx-*/rps_flow_cnt)
do
    echo $rfc > $fileRfc
done

tail /sys/class/net/eth*/queues/rx-*/{rps_cpus,rps_flow_cnt}

higkoo

5

老的内核会有这个问题不? 是压测是时候一直都是首核比其他核高, 还是压测到极限的时候突然涨高了? 还有看看 /proc/softirqs 是不是网卡软中断打满的

我压测只设置了软中断均衡, 压测到极限也相对比较均衡. 内核 3.17.2 下面是我的压测时的softirq:

top - 13:52:59 up 36 days, 13:31,  1 user,  load average: 16.97, 6.95, 2.66
Tasks: 332 total,  13 running, 319 sleeping,   0 stopped,   0 zombie
Cpu0  :  7.4%us, 29.4%sy,  0.0%ni, 37.8%id,  0.0%wa,  0.0%hi, 25.4%si,  0.0%st
Cpu1  :  7.7%us, 32.7%sy,  0.0%ni, 43.4%id,  0.0%wa,  0.0%hi, 16.2%si,  0.0%st
Cpu2  :  7.0%us, 30.8%sy,  0.0%ni, 38.1%id,  0.0%wa,  0.0%hi, 24.1%si,  0.0%st
Cpu3  :  8.0%us, 30.8%sy,  0.0%ni, 40.8%id,  0.0%wa,  0.0%hi, 20.4%si,  0.0%st
Cpu4  :  9.1%us, 28.6%sy,  0.0%ni, 40.7%id,  0.0%wa,  0.0%hi, 21.5%si,  0.0%st
Cpu5  :  7.4%us, 31.8%sy,  0.0%ni, 39.5%id,  0.0%wa,  0.0%hi, 21.4%si,  0.0%st
Cpu6  :  7.7%us, 30.8%sy,  0.0%ni, 40.1%id,  0.0%wa,  0.0%hi, 21.4%si,  0.0%st
Cpu7  :  7.7%us, 31.4%sy,  0.0%ni, 40.5%id,  0.0%wa,  0.0%hi, 20.4%si,  0.0%st
Cpu8  :  8.1%us, 29.9%sy,  0.0%ni, 37.9%id,  0.0%wa,  0.0%hi, 24.2%si,  0.0%st
Cpu9  :  8.1%us, 30.3%sy,  0.0%ni, 37.4%id,  0.0%wa,  0.0%hi, 24.2%si,  0.0%st
Cpu10 :  7.4%us, 32.4%sy,  0.0%ni, 42.5%id,  0.0%wa,  0.0%hi, 17.7%si,  0.0%st
Cpu11 :  7.3%us, 31.7%sy,  0.0%ni, 40.7%id,  0.0%wa,  0.0%hi, 20.3%si,  0.0%st
Cpu12 :  8.3%us, 31.6%sy,  0.0%ni, 40.5%id,  0.0%wa,  0.0%hi, 19.6%si,  0.0%st
Cpu13 :  7.0%us, 31.2%sy,  0.0%ni, 40.2%id,  0.0%wa,  0.0%hi, 21.6%si,  0.0%st
Cpu14 :  8.3%us, 30.7%sy,  0.0%ni, 39.3%id,  0.0%wa,  0.0%hi, 21.8%si,  0.0%st
Cpu15 :  7.7%us, 31.0%sy,  0.0%ni, 40.4%id,  0.0%wa,  0.0%hi, 20.9%si,  0.0%st
Cpu16 :  5.7%us, 26.0%sy,  0.0%ni, 53.0%id,  0.0%wa,  0.0%hi, 15.2%si,  0.0%st
Cpu17 :  5.0%us, 24.5%sy,  0.0%ni, 50.7%id,  0.0%wa,  0.0%hi, 19.8%si,  0.0%st
Cpu18 :  5.7%us, 25.5%sy,  0.0%ni, 50.3%id,  0.0%wa,  0.0%hi, 18.5%si,  0.0%st
Cpu19 :  5.6%us, 25.5%sy,  0.0%ni, 50.3%id,  0.0%wa,  0.0%hi, 18.6%si,  0.0%st
Cpu20 :  5.4%us, 26.5%sy,  0.0%ni, 47.6%id,  0.0%wa,  0.0%hi, 20.4%si,  0.0%st
Cpu21 :  6.3%us, 26.2%sy,  0.0%ni, 46.0%id,  0.0%wa,  0.0%hi, 21.5%si,  0.0%st
Cpu22 :  5.8%us, 24.4%sy,  0.0%ni, 48.8%id,  0.0%wa,  0.0%hi, 21.0%si,  0.0%st
Cpu23 :  6.7%us, 24.1%sy,  0.0%ni, 49.8%id,  0.0%wa,  0.0%hi, 19.4%si,  0.0%st
Cpu24 :  6.7%us, 23.3%sy,  0.0%ni, 42.3%id,  0.0%wa,  0.0%hi, 27.7%si,  0.0%st
Cpu25 :  6.0%us, 25.2%sy,  0.0%ni, 46.7%id,  0.0%wa,  0.0%hi, 22.2%si,  0.0%st
Cpu26 :  6.4%us, 25.5%sy,  0.0%ni, 47.3%id,  0.0%wa,  0.0%hi, 20.8%si,  0.0%st
Cpu27 :  5.6%us, 26.2%sy,  0.0%ni, 46.8%id,  0.0%wa,  0.0%hi, 21.3%si,  0.0%st
Cpu28 :  5.7%us, 25.2%sy,  0.0%ni, 49.0%id,  0.0%wa,  0.0%hi, 20.1%si,  0.0%st
Cpu29 :  6.3%us, 25.3%sy,  0.0%ni, 47.0%id,  0.0%wa,  0.0%hi, 21.3%si,  0.0%st
Cpu30 :  6.0%us, 24.1%sy,  0.0%ni, 48.5%id,  0.0%wa,  0.0%hi, 21.4%si,  0.0%st
Cpu31 :  5.9%us, 24.1%sy,  0.0%ni, 47.9%id,  0.0%wa,  0.0%hi, 22.1%si,  0.0%st

rps设置脚本:

$cat soft.sh 
#!/bin/bash
list=`seq 0 31`
if [ -z "$value" ]; then
  aff=ffffffff
  fcnt=4096
else
  aff=0
  fcnt=0
fi
cnt=0
for i in $list
do
 echo /sys/class/net/eth0/queues/rx-${i}
 echo $aff > /sys/class/net/eth2/queues/rx-${i}/rps_cpus
 echo $aff > /sys/class/net/eth3/queues/rx-${i}/rps_cpus
 echo $fcnt > /sys/class/net/eth2/queues/rx-${i}/rps_flow_cnt
 echo $fcnt > /sys/class/net/eth3/queues/rx-${i}/rps_flow_cnt
 cnt=$((cnt+fcnt))
done
echo $cnt > /proc/sys/net/core/rps_sock_flow_entries
cat /proc/sys/net/core/rps_sock_flow_entries

taoyuanyuan

5

还有我看你的 listen socket的backlog设置的是 128. 高并发压测下如果满了也可能会导致半连接队列的socket不能放入已连接队列, 半连接队列满了之后, 导致连接超时或者错误. 可以设置大些看看, 比如

listen 80  backlog=20480;

taoyuanyuan

2

内核3.13 参数 net.ipv4.tcp_max_syn_backlog=262144 net.core.somaxconn=262144 修改了为啥还是backlog 511 难道必须得在nginx listen 80 backlog=20480 由于我有多个80 server_name 不同，但是每个80 backlog都配置backlog 就有问题，貌似只能配置一个。

lidaohang

8

一. 在linux平台下有如下代码:

#define NGX_LISTEN_BACKLOG        511

ls[i].backlog = NGX_LISTEN_BACKLOG;
listen(s, ls[i].backlog)

在nginx的listen指令没有配置backlog时候, 默认最终传递给listen系统调用的backlog为 511. tcp最终生效会选择小的那个值 min(somaxconn, backlog), 所以最终会使用 511.

二. 同一个端口配置一次就行了, 对所有的都生效.

taoyuanyuan

2

好的，感谢了~ 那我多个配置文件，里面多个80，不同的server_name 配置一个，对所有的都是生效的吧~ 我试试

lidaohang

1

backlog只配置一个就可以了，通用。

imleon

0

有谁用阿里云测试过吗? 我在阿里云的CentOS7上跑tengine,官方配置,16核16G echo 'ffff'|sudo tee /proc/irq/146/smp_affinity echo 'ffff' |sudo tee /sys/class/net/eth0/queues/rx-0/rps_cpus

十台客户端只能压到60000qps ansible all -m command -a"ab -r -n 300000 -c 500 -k \"http://10.161.84.214:81/empty.gif\"" -f 10

Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle Average: all 3.35 0.00 4.02 0.05 0.01 9.14 2.66 0.00 0.00 80.77 Average: 0 4.62 0.00 4.76 0.00 0.00 37.66 2.67 0.00 0.00 50.29 Average: 1 3.24 0.00 3.82 0.00 0.00 7.34 2.45 0.00 0.00 83.15 Average: 2 3.54 0.00 4.55 0.00 0.04 7.23 2.36 0.00 0.00 82.28 Average: 3 3.38 0.00 3.52 0.00 0.00 7.84 2.34 0.00 0.00 82.93 Average: 4 3.52 0.00 4.63 0.00 0.00 7.07 2.69 0.00 0.00 82.08 Average: 5 3.29 0.00 3.65 0.00 0.00 7.11 3.00 0.00 0.00 82.95 Average: 6 3.24 0.00 3.70 0.00 0.00 7.95 2.52 0.00 0.00 82.60 Average: 7 3.30 0.00 4.38 0.00 0.00 7.07 2.69 0.00 0.00 82.57 Average: 8 2.98 0.00 3.62 0.00 0.04 7.43 2.62 0.00 0.00 83.32 Average: 9 3.09 0.00 4.32 0.00 0.00 6.41 2.70 0.00 0.00 83.48 Average: 10 3.37 0.00 3.37 0.00 0.00 7.63 3.12 0.00 0.00 82.52 Average: 11 2.87 0.00 3.05 0.00 0.00 7.28 2.94 0.00 0.00 83.87 Average: 12 2.98 0.00 3.77 0.00 0.00 6.96 2.65 0.00 0.00 83.64 Average: 13 3.37 0.00 3.91 0.86 0.00 7.38 3.65 0.00 0.00 80.83 Average: 14 3.41 0.00 4.42 0.00 0.00 7.18 2.19 0.00 0.00 82.79 Average: 15 3.24 0.00 4.86 0.00 0.00 7.38 1.98 0.00 0.00 82.54

yc850k

1

感谢各位，原因知道了。是因为系统设置的 somaxconn 太大导致（1048576）。 CentOS系统这个值设大不报错，而且sysctl查看显示设定生效的。（但Nginx的accept显示变成默认128了，坑爹）而在 Debian 系统里，somaxconn 不能超过 65535，否则执行就报错！

higkoo

[alibaba/tengine]开启reuse_port后大压力下出现连接超时的现象

回答