業務慢故障分析-查詢錯誤導緻一、故障描述二、故障分析三、結論

某二級政府機關網絡，網絡管理人員經常接到使用者反映業務系統通路比較慢，而此時網絡運作良好，并不存在網絡問題。基于這種情況，我們對網絡進行了資料流分析。網絡及部署情況大緻如下：

如上圖，該網絡為省級機關的應用伺服器區，通過各下級機關通過廣域網通路應用伺服器，科來回溯分析系統部署在核心交換的鏡像端口。

通過流量、資料包、使用率、TCP Flags關鍵參數的圖形化顯示，快速了解網絡運作狀況；并通過網絡協定，實體端點、IP端點、實體會話、IP會話、TCP會話、UDP會話等多角度、深層次的對資料進行關聯挖掘，直覺地展現各網絡對象間的關聯關系和資料統計結果，進而全面展現網絡的工作狀态，是否存在風險和隐患等問題。

最後通過提取資料包(Packets)，通過解碼、會話分析等驗證結論過解碼驗證分析結果。資料包分析将按照以下兩種方法進行：

1. 資料包分析法

對捕獲下來的資料包進行統計分析，解碼分析（關鍵字段），專家分析。

2. 同步對比分析法

在不同的位置同時捕包，并采用資料包分析方法對資料進行對比分析的方法。

整個測試分析過程嚴格遵循以上流程，即“全局—>節點（會話）—>資料包”的分析方法。

本次分析仍然使用診斷-->定位位址-->定位資料包---〉分析這個傳統的分析思路。

根據使用者回報的時間，定位到相關時間段，如下圖：

選中相關資料包，調用專家分析進行診斷

科來回溯分析系統提供了專家分析功能，可以智能的對網絡中的一些安全、性能、故障問題進行快速的定位。

專家分析系統提供了快捷的分析體系，可通過診斷三步曲，來實作對異常現象的快速定位、識别分析。

第一步，先找出網絡中存在的異常現象，本次發現了TCP慢應答報錯，關于TCP慢應答的相關解釋資訊，可在診斷條目中輕按兩下該條目擷取，如下圖：

第二步，定位診斷發生的位址，如上圖中詳細的提供了發生TCP慢應答的主機，并提供了各主機出現慢應答的次數，并支援對次數排名，如下圖：

其中伺服器16.205出現的次數最多，達到了402個，接下來需要對該主機的TCP會話資訊進行深入分析。

第三步，選中該主機，定位到診斷事件，快速調去相關資料包，如下圖：

通過如上三步曲，我們選中了25.157:1304<--->16.205:1521這個會話進行詳細分析，通過對TCP會話互動資訊，确定應用慢具體慢在什麼地方。

如上圖，在TCP會話中顯示該會話條目，輕按兩下進入TCP流分析界面，如下圖：

選中的該會話持續了29.45s，傳輸了139.714K位元組，共522個資料包。

打開TCP交易清單，對TCP會話包括的所有交易情況進行分析，如下圖：

選取請求3與響應3的的時間內插補點來簡單評估伺服器的響應時間，我們可以看到在該伺服器響應中，隻用了0.815ms，可以說伺服器性能良好。

而在後續的交易中，伺服器響應時間也相對較快，其中下圖中的紅色标示部分為伺服器響應時間：

在上圖中，我們可以清晰的看到響應時間一般在0.3ms左右，最高也不過0.5ms。

繼續分析該會話的交易資訊，發現在序列号193、194、195這三個資料包之間出現了比較大地逾時，如下圖：

而在序列号為193的資料包解碼中，看到ORA-01403: no data found字樣。

結合上下文，該no data found響應，是由于用戶端進行如下操作時造成：

select count ( *) from xxx*ba where xx* =:1 and xxbz ='Y' and q_q <= :2 and ( xxx) ，（一條select語句）如下圖所示：

由于這樣一個操作導緻了将近2.5s的時間停頓，如下圖：

繼續分析該會話，又在序列号230、231、232這三個資料包之間出現了一個長達8.9s的傳輸停頓，如下圖：

同樣這個停頓也是由于用戶端收到了一個no data found的報錯，如下圖：

而本次用戶端上一個操作為：Select Max （xx） From xx Where x =:1 and xx_xx =:2 and

接下來在序列号為244、245、246這三個資料包之間又出現了10.4s的時間停頓，如下圖：

同樣這個停頓了也伴随了no data found，而這次用戶端的操作為：Select MBFS from xx where xx =:1，

綜合本次會話中的3次no data found停頓，共造成了2.5+8.9+10.4=21.8s的延時，而整個會話總共為29.4s。也就是在這個29.4s的會話中隻有7.6s的時間用于傳輸有效資料，其中21.8s的時間用于時間停頓，也就造成了該應用的使用者體驗較差。

業務通路慢問題，主要由于用戶端的查詢錯誤導緻長時間停頓造成。其中在截取的29.4s會話中，隻有不足三分之一的時間用于有效的請求、響應及資料傳輸，大量時間用于停頓。

關于造成該停頓的原因可能跟該應用的用戶端程式設計有關，需進一步跟相關應用開發人員協商，準确定位問題原因。

此次分析的入手點是診斷資訊定位到的TCP慢反應，需注明此資訊與最終的診斷原因并無明顯的必然聯系，希望大家不要誤解。而之是以從此特征能成功找到故障根源，跟網絡中該業務資料流較大，且更多會話中都存在該查詢等錯誤有關。

本文轉自此号無效1 51CTO部落格，原文連結:http://blog.51cto.com/test2016/777791

業務慢故障分析-查詢錯誤導緻一、故障描述二、故障分析三、結論

繼續閱讀

RMI vs Socket 比較

Rmi和Socket比較

RMI 和 Socket 差別簡介

網絡連接配接錯誤代碼大全及解決方法

HTTP 錯誤 403.9 - 禁止通路：連接配接的使用者過多 XP IIS伺服器連接配接數的修改

TCP和UDP傳輸的深入淺析,MSN和QQ檔案傳輸速度解析

UECapabilityInformation中bandEUTRA 64的含義

網絡通信原理OSI參考模型TCP/IP協定簇數值轉換IP位址分類子網路遮罩

QQ for Linux釋出帶來的感想。

事務（髒讀，不可重複讀，虛讀）

華為交換機與中興交換機結合配置MSTP執行個體

Socket套接字類 AS3

2.6核心netfilter包截獲

網絡協定之網頁資料包到伺服器的傳輸過程

圖解HTTP八：确認通路使用者身份的認證

在一個非套接字上嘗試了一個操作