我在确保通过 10GbE 网络接口连接到 Signal Hound 频谱分析仪的服务器上达到所需的网络吞吐量时遇到了麻烦。基本上，当只有无线电捕获进程运行时，我可以获得良好的吞吐量，但是当我运行其他进程时，吞吐量开始下降。我正在使用 Aquantia PCIe 以太网适配器和 QNAP SFP+ 10GbE Thunderbolt 3 适配器。
当我运行一个简单的 Python 程序以流模式轮询频谱分析仪 API 时，在最大带宽（~800MB/s）下一切都运行良好。当我这样做时
$ stress --cpu 8 --io 8 --vm 8 --hdd 8
并排时，它降低到大约 600MB/s 并且我开始丢失大量数据。
我尝试过的事情：
- 更新驱动程序
- 弄乱合并参数和许多 ethtool 选项（MTU 等）
- 关闭超线程并通过 CPU 亲和性固定将进程隔离到单个核心（8 个中的 8 个）
- 这还涉及将网络中断隔离到其自己的核心（8 个中的 7 个）
- 我还将核心调节器改为“性能”，这样它就总是处于最大频率
- 我还尝试关闭核心 7 和 8 的大多数其他中断，以防止它们变慢，这已通过 netdata 仪表板验证
- 我基本上尝试了一切这里
从本质上讲，我知道它可以实时运行，因为当它本身被限制在 2 个核心上时，它可以正常工作。但出于某种原因，即使其他核心不会干扰 CPU 周期或网络 IRQ，当核心 1-6 处于高负载时，它们也会大大减慢主进程的速度。
如果有帮助的话，我发现该--vm 4选项stress会导致速度最慢，所以我怀疑它与内存分配以及网卡的 DRAM 接口有关。
我几乎要绞尽脑汁才能在一台（应该非常强大的）Ubuntu 20.04机器上从无线电中获取每个数据包。有人有使用过这样的应用程序吗？
编辑：我在这里复制了一些性能曲线：
这是我看到的效果
这是利用率。在高压力期间和“仅捕获”期间，核心 6 的软中断利用率都达到 100%。我尝试将网络数据拆分到两个核心（5 和 6）上，但其中一个核心始终保持加载状态，而另一个核心似乎很清晰，即使它们的中断数量相似。
不幸的是，在压力测试运行期间，CPU 6 上的实际软中断数量会下降。
这是我在 CPU6 软网络上看到的效果。
此外，中断似乎保持相对不变，尽管在高压力期间中断的一致性会降低一些。
这是直线网络速度，两个时期的速度看起来也有点不一致。
我仔细查看了异常情况（尽管 netstat 中有很多图表），看起来在高压力期间没有进程间内存。这会导致问题吗？
如果有人需要更多图表，请告诉我。我无法从这些图表中推断出问题所在，但我希望这些信息足以找到潜在的解决方案。
再次感谢！
答案1
好了，我想我已经找到问题的答案了。我认为这里的关键图表是“softirq”图表。在正常运行下，我认为它不应该那么高。
我在分析时遇到了一点小麻烦：基本上，因为我正在运行 CUDA 和一堆其他需要繁琐安装的库，所以我在 docker 容器中运行所有这些（我知道你们都在说什么！）。由于我没有在 docker 中处理无线电的网络内容，所以我没有考虑过它。是的，你猜对了，docker 网络增加了足够的处理能力，使我越过边缘，丢掉了数据包。我最终将其设置network_mode为host使用主机网络，这解决了我的问题。希望这对其他人有帮助！
但这还不是全部——为了弄清楚这一点，我花了很多时间进行分析，以弄清楚我到底为什么会看到这种效果（感谢@AlexD 提供的资源）。这是运行 API 驱动程序的固定 CPU 7 的火焰图：
如您所见，它在页面错误内存分配上花费了大量时间（这应该是另一个线索，尽管我没有在这里发布它。捕获期间，小内存错误激增）。这解释了为什么运行会stress产生--vm 4最差的结果——它引起了内存争用，从而大大降低了驱动程序的速度。此外，经过一些测试后，我认为它无论如何都需要多个核心（它专门丢弃固定到核心 7 的数据包，但固定到 6 和 7 的数据包可以正常工作）。超频后我得到了更好的结果（但仍然不完美），这解释了原因。
所以，您已经了解了：为什么所有事情都是这样发生的，并有图表支持。我有两个核心的无线电 API 利用率约为 60%，并且它在获取所有数据包方面相当稳定（另一个核心处理软中断的比例约为 10%，低于上图中的 95%）。我觉得自己有点愚蠢，没有想到 docker 会拖慢我的速度，但弄清楚这一切后感觉好多了。希望这篇文章能帮助别人！