“偵破”網卡傳輸能力的“個”案

作者：李燁楠

一個平靜的下午，在某監控大廳，應急召集令發出，一時間應急電話、匯報、詢問聲音響成一片。這是怎么了？原來某重要+系統應用交易嚴重超時，業務產生大量積壓，無法順利進行。

一、問題到底出在哪里?

系統架構簡單明了：后臺為Oracle RAC DB數據庫，前臺為12臺AP，AP連接到DB做業務。而業務處理響應緩慢的情況發生在所有的AP上，因此焦點集中到DB服務器、網絡、存儲等共用的資源及設備上。

經過各方的共同排查，存儲正常、數據庫正常，卻發現DB與AP的網絡通信存在問題，ping延時嚴重，AP與DB、DB與DB之間的ping延時達到十幾毫秒并且一直持續(正常時的ping延時只有0.3毫秒左右)。 于是，網絡與系統開始協同檢查抓包，發現網絡鏈路上未見異常，十幾毫秒的延時都消耗在DB主機的響應時間上，系統上可見所有資源均正常，網卡流量遠未達到瓶頸，只有網卡收發包數一直較大。

二、抽絲剝繭的分析,提出解決方案

到底是什么具體問題呢？讓我們先來看看問題主機的環境：Power780物理機，生產、帶管、心跳網卡均為etherchannel綁定的網卡，使用的是兩塊千兆網卡，由于為主備模式，實際只有一塊網卡處于工作狀態。

根據之前我們在PowerVM虛擬化環境應急的經驗，懷疑是單塊千兆網卡轉發包數的處理能力達到了瓶頸。通過AIX的topas、nmon等工具都可以很方便的監控每秒網卡的接收及發送數據包數，查詢結果如下：

總結

以上是生活随笔為你收集整理的万兆网卡实际吞吐量_案例探索 | 千兆/万兆网卡每秒转发包数处理能力上限到底有多大？...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。