如何在重負載下確保 ubuntu 20.04 上 10GbE 網路設備的吞吐量
我無法確保通過 10GbE 網路介面連接到 Signal Hound 頻譜分析儀的伺服器上所需的網路吞吐量。基本上，當只執行無線電擷取程序時，我可以獲得良好的吞吐量，但是當我執行其他程序時，吞吐量開始下降。我正在使用帶有 QNAP SFP+ 10GbE Thunderbolt 3 適配器的 Aquantia PCIe 乙太網適配器。
當我執行一個簡單的 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 機器上的無線電中獲取每個數據包。有沒有人有這樣的應用程序的經驗？
編輯：我在這裡複製了一些性能曲線：
這是我看到的效果
所以這裡是使用率。Core 6 在高壓力期間和“剛剛擷取”期間都處於 100% 的軟中斷狀態。我嘗試將網路數據拆分到兩個核心（5 和 6）上，但其中一個始終保持載入，而另一個看起來很清晰，即使它們有相似數量的中斷。
不幸的是，在執行壓力測試期間，CPU 6 上的軟中斷的實際數量下降了。
這是我在 CPU6 softnet 上看到的效果。
此外，中斷似乎保持相對相同，儘管在高壓力期間它們變得不太一致。
這是直接的網路速度，在兩個時期看起來也有點不一致。
我非常仔細地尋找異常情況（儘管 netstat 中有很多圖），並且看起來在高壓力期間沒有程序間記憶體。這會導致問題嗎？
如果有人需要更多的情節，請告訴我。我無法從這些中推斷出問題，但我希望有足夠的資訊來提出潛在的解決方案。
再次感謝！
好的，我想我已經找到了我的問題的答案。我認為這裡的關鍵圖是“softirq”圖。在正常操作下，我認為應該不會那麼高。
在進行分析時，我有一點點 d’oh 時刻：基本上，因為我正在執行 CUDA 和一堆其他繁瑣的安裝庫，所以我在 docker 容器中執行所有這些（我知道你們都在說什麼！） . 由於我沒有在 docker 中搞亂收音機的網路內容，所以我沒有考慮過。是的，你猜對了，docker 網路增加了足夠的處理能力，讓我越過邊緣丟棄數據包。我最終將 to 設置
network_mode為host使用主機網路，它解決了我的問題。希望這對其他人有幫助！但這還不是全部——為了弄清楚這一點，我花了很多時間進行分析，以弄清楚為什麼我看到了我所看到的效果（感謝 @AlexD 提供的資源）。這是執行 API 驅動程序的固定 CPU 7 的火焰圖：
正如你所看到的，它在頁面錯誤記憶體分配上花費了很多時間（這應該是另一個線索，雖然我沒有在這裡發布它。在擷取期間，輕微的記憶體錯誤是通過屋頂）。這就解釋了為什麼執行
stresswith--vm 4會產生最差的結果——它會導致記憶體爭用，從而顯著降低驅動程序的速度。此外，在對其進行了一些測試之後，我認為它無論如何都需要一個以上的核心（它只丟棄固定在核心 7 上的數據包，但在固定到 6 和 7 時工作）。超頻後我得到了更好的結果（但仍然不完美），這就解釋了原因。所以你有它：解釋為什麼這一切都以它的方式發生，並用圖表來支持它。我在無線電 API 的兩個核心上有大約 60% 的使用率，並且它在獲取所有數據包方面非常穩定（另一個核心處理軟中斷大約為 10%，低於您在上圖中看到的 95%）。我沒有想到 docker 會減慢我的速度，我覺得有點愚蠢，但是把這一切都弄清楚了要好得多。希望這篇文章可以幫助別人！
