DPDK 网关性能瓶颈分析

发布于 2021-03-08 16:06:04 字数 2632 浏览 1672 评论 0

我们线上环境部署的基于 Open vSwitch 的 DPDK 技术实现的专线网关,前段时间遇到了用户特定业务流量导致 网关性能异常下降的问题。普通情况下,根据我们自己的测试结果,单台网关使用 Intel/Mellanox 25G 网卡, 测试流量打固定端口,单向转发性能可以达到 900 万以上的 PPS,随机端口流量也可以达到 500~600 万的PPS。 但是当用户特定的业务流量走网关时,网关的转发性能会骤降到 120 万PPS左右,影响用户的线上业务。

在问题发生时,我们可以在网关观察到 ovs pmd 统计结果的 megaflow hits 和处理每个报文的 cpu cycle 偏高:

问题重现

在问题出现后,我们迅速扩容了一批网关,第一时间先解决用户的性能需求。同时另外准备了一批测试机器, 尝试重现用户的问题。 通过准备的10台物理服务器和30台云主机,走网关模拟的用户的流量模型,经过各种尝试后,终于重现了 用户遇到的问题。

我们发现重现用户问题需要满足两个条件:

  • 大量TCP短连接
  • 网关处于高负载状态

我们在测试的机器上通过并发跑 netperf TCP_CRR 测试将网关打满,便可以重现这个场景。

问题分析

确认问题出现的场景后,我们团队提出了几个可能出现问题的地方:

  • Open vSwitch 的 EMC 缓存耗尽,报文转发走了效率更低的路径
  • Open vSwitch 的 socket-mem 内存资源耗尽,申请内存导致了性能下降
  • 网卡队列的CPU core绑定/NUMA绑定出现了错误
  • 网卡驱动的问题,等等

对于ovs emc缓存耗尽的猜测,我们通过升级ovs版本、开启smc缓存,问题仍然存在,排除可能。 对于ovs socket-mem 不够大的猜测,我们通过修改ovs配置大幅增加其大小,问题仍然存在,排除可能。 对于网卡队列的cpu/numa绑定出错的猜测,我们确认了没有使用CPU超线程core、处理单侧流量的网卡队列的 pmd绑定在相同的numa节点上,排除可能。 对于网卡驱动可能有问题的猜测,我们测试了Intel和Mellanox的网卡,都存在相同的问题,也排除了可能。

猜测可能出现问题的地方都排除了可能,只能直接分析ovs的调用堆栈分析原因了。

首先我使用perf/flamegraph工具,绘制了60s ovs pmd线程的cpu火炬图。

可以看到大量的CPU时间都消耗在了pthread等锁的函数调用上,但是从火炬图还是无法确认具体原因。

于是我又编写了一个调试脚本,循环调用gdb打印ovs pmd线程的调用堆栈,看看从结果能不能找出头绪, 终于有了新发现!

从我们脚本的统计结果可以看到,超过三分之一的ovs pmd线程都处于 meter_lock 这个锁函数上, 原因应该就是这里了,也就是ovs的meter功能导致的问题。

我们在测试网关上配置了跳过ovs meter的流表,网关性能瞬间恢复了正常。

由于线上的网关基本都是用户独占使用,关闭 ovs meter(qos) 功能并不会影响用户的实际使用, 为了快速解决线上的这个问题,我们迅速开发了跳过ovs meter 的 api 开关以解决用户网关的这个问题。

对于 ovs,可能是由于代码实现、性能优化不到位导致了这个问题,有待我们继续对 ovs 源码进行分析。

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据

关于作者

JSmiles

生命进入颠沛而奔忙的本质状态,并将以不断告别和相遇的陈旧方式继续下去。

0 文章
0 评论
84961 人气
更多

推荐作者

已经忘了多久

文章 0 评论 0

15867725375

文章 0 评论 0

LonelySnow

文章 0 评论 0

走过海棠暮

文章 0 评论 0

轻许诺言

文章 0 评论 0

信馬由缰

文章 0 评论 0

    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文