iqiyi / dpvs

DPVS is a high performance Layer-4 load balancer based on DPDK.
Other
3.04k stars 730 forks source link

dpvs fullnat 模式下,wrk测试会有timeout #1003

Open mztmyf opened 1 month ago

mztmyf commented 1 month ago

在fullnat模式下,两个网卡均为10Gbps,使用wrk测试,发现当带宽超过5Gps时,会出现timeout,超过的越多,timeout的数量也越多,如果通过wrk直接测试RS 不存在该问题,请问是dpvs配置问题吗?能提供什么排查思路吗,谢谢 dpip link show -s 看的话也没有发生错误

ywc689 commented 1 month ago

dpip addr show -s 检查有无sa_miss.

mztmyf commented 1 month ago

dpip addr show -s dpip addr show -s 显示都正常。 dpvs的统计数据都显示正常,除了dpip -s link show cpu里面有一些dropped。 另外我们开启了redirect on, 这个会有影响吗

mztmyf commented 1 month ago

dpip addr show -s dpip addr show -s 显示都正常。 dpvs的统计数据都显示正常,除了dpip -s link show cpu里面有一些dropped。 另外我们开启了redirect on, 这个会有影响吗

另外如果只挂一个rs, 带宽基本上跑满也不会出现timeout, 如果挂两个rs,就容易出现。

ywc689 commented 1 month ago

redirect 比较影响性能,可以关掉试试。RS数量通常对性能影响不大。

mztmyf commented 1 month ago

redirect

关掉redirect话,会导致tcp建联偶尔出错,参考的 #738 开启了redirect解决,而且我看了我的网卡驱动ixgbe是支持rtc_flow的。

mztmyf commented 1 month ago

redirect

关掉redirect话,会导致tcp建联偶尔出错,参考的 #738 开启了redirect解决,而且我看了我的网卡驱动ixgbe是支持rtc_flow的。

通过配置mode signature 解决了redirect的问题,但是timeout还是大量存在 抓包看,是rs发送给client的包有大量的重传,而且重传时间比较长,带宽还是充裕的

ywc689 commented 1 month ago

signature 配置多个local ip可能会冲突,你测试的fullnat ipv6吗? ixgbe网卡是支持ipv4 perfect匹配的。

mztmyf commented 1 month ago

signature 配置多个local ip可能会冲突,你测试的fullnat ipv6吗? ixgbe网卡是支持ipv4 perfect匹配的。

  1. 前面说的有问题,配置的是ipv4的prefect, 每个cpu配置一个queue 是不需要开启redirect的。建联都正常的。
    1. local ip 1个和多个都测试了, 都会出现大量的timeout
    2. 目前我们只有ipv4转发的场景,没有v6的ip。
    3. 带宽超过网卡一半时,就开始出现timeout
mztmyf commented 1 month ago

从抓包看的话,基本上每个链接都会收到异常的tcp seq 数据,导致后续的数据都认为是重传了,目前怀疑有两个原因:

  1. dpvs转发数据出错,把其数据转发到了其他链接上。导致数据异常。这个加了日志观察了 lookup conn都是正常的。
  2. dpvs 处理tcp数据异常,导致seq写入了错误的值。
    请教下dpvs会重写seq吗? 或者有其他排查思路吗? 目前是只要后端挂超过一个rs 就是必现的。
mztmyf commented 1 month ago

image 异常抓包。no.2160的包seq明显异常,导致wireshark认为抓包有丢失,并且认为后面正常的包都是重传包。

ywc689 commented 1 month ago
  1. 如两个RS的IP:port是不同的,这种情况原理上是不可能出现的。但fnat大并发时连接可能发生连接重用,如果rs不能快速释放tcp连接,可能导致异常。
  2. fnat会调整seq,但这与流量和并发量无关。

另外,单个RS正常,两个RS不正常,这种现象比较奇怪,我们没有遇见过。一般情况,在一定范围内,RS越多,性能数据会越好。

从抓包看的话,基本上每个链接都会收到异常的tcp seq 数据,导致后续的数据都认为是重传了,目前怀疑有两个原因:

  1. dpvs转发数据出错,把其数据转发到了其他链接上。导致数据异常。这个加了日志观察了 lookup conn都是正常的。
  2. dpvs 处理tcp数据异常,导致seq写入了错误的值。 请教下dpvs会重写seq吗? 或者有其他排查思路吗? 目前是只要后端挂超过一个rs 就是必现的。