# 網絡基本功（二十九）：Wireshark抓包實例診斷數據庫常見問題 **轉載請在文首保留原文出處：EMC中文支持論壇**[https://community.emc.com/go/chinese](https://community.emc.com/go/chinese) [](https://community.emc.com/servlet/JiveServlet/showImage/2-872167-108601/image001.gif) ## 介紹 通常來說，數據庫，應用和網絡在IT架構中處于不同的分支。數據庫的故障排查由DBA來完成，但是網絡工程師仍可以從抓包中定位出問題并不出自網絡。當IT抱怨“網速慢”，實際并不一定是這樣。下文幫助我們驗證所謂“網速慢”的問題。 ## 更多信息 **工作過程:** 對于數據庫問題，按照以下步驟： 1. 當懷疑是“慢速網絡響應”時，問以下問題： * 問題發生于本地還是全局？是只發生在遠端辦公室，還是center也有發生？如果整個網絡都出現問題，就不會是WAN帶寬問題。 * 對于所有客戶端是否都發生了這樣的問題？如果只是某些特定用戶碰到問題，則可能是這些用戶運行了某些應用導致。 * 客戶端和服務器之間通訊鏈路是否過載？導致過載的應用是什么？ * 是所有應用都運行緩慢，還是使用特定數據庫的應用運行緩慢？是PC比較老舊，還是服務器資源耗盡? 2. 搞清楚上述問題之后，開始故障排查： 1\. 打開Wireshark開始抓包。可以將對端端口連到PC，服務器，VLAN，或連接遠端客戶端的路由器。 2\. 在expert info中查看TCP事件。這些事件發生在整個通信鏈路，或是特定的IP地址，還是特定的TCP端口？此操作能夠幫助定位問題并驗證是否發生于特定鏈路，服務器，或是應用。測試連接到Internet的數據流時，可能會得到發往站點或mail server（諸如此類）的很多重傳以及重復ACK。在組織內部，重傳范圍應當在百分之0.1至0.5。連接到Internet時，可能會高得多。 3. 當你看到網絡上有問題時，按照前幾張的故障排查步驟給予解決。但是，也有些網絡問題會影響數據庫操作。下例中，可看到客戶端與服務器通信鏈路往返延時達到35至40ms。 1\. 我們查看TCP stream 8（1），連接開始于TCP SYN/SYN-ACK/ACK。如下圖（2）所示。可以看到整個連接花費了371個報文（3）。 [](https://community.emc.com/servlet/JiveServlet/showImage/2-872167-108602/image002.jpg) 2\. 連接繼續，可見到DB請求與響應之間時間間隔大約35ms。 [](https://community.emc.com/servlet/JiveServlet/showImage/2-872167-108603/image003.jpg) 3\. 由于往返已經有371個報文，371X35 ms大約是13秒。加上可能發生一些重傳導致延時，用戶查詢一次數據庫可能要等待10至15秒。 4\. 這種情況下，應當與DBA討論怎樣大幅減少網絡上傳輸的報文數量，或是改變終端服務器或網絡接入的方式。 4. 另一個可能發生的問題是抓包文件反映出有軟件問題。以下截圖中可看到5個重傳（1），并且客戶端打開了一個新的連接（3）。看起來像一個TCP問題但只發生在軟件中一個特定窗口。這只是由于一個軟件進程停止運行，因此TCP無法對客戶端作出響應（2）。 [](https://community.emc.com/servlet/JiveServlet/showImage/2-872167-108604/image004.jpg) **更多建議：** 右鍵數據庫客戶端與服務器會話報文，會打開一個窗口，有助于DBA查看網絡問題。當碰到延時問題時，例如，通過移動電話接入Internet，數據庫客戶端到服務器的通訊可能效率低下。可能需要切換接入方式。 很重要的一點是搞清楚數據庫的工作模式。如果客戶端正在接入數據庫服務器，數據庫服務器正在使用從另一臺服務器共享的文件，可能客戶端——服務器工作良好，但問題可能出在數據庫服務器與文件服務器之間共享文件上。確保在開始測試之前確知所有依賴條件。 最重要的是，與DBA保持良好關系。 ## 參考 Network Analysis Using Wireshark Cookbook