背景

某企業(yè)開發(fā)環(huán)境用戶反應，在相同的機房，相同網(wǎng)段，不同IP地址的mysql服務器，相同訪問，一個響應很快，一個明顯的慢。

納悶之余，網(wǎng)深科技工程師幫其分析了原因。

分析之前，先約定一下，以下對響應快的簡稱“很快”，響應慢的簡稱“很慢”吧。

故障復現(xiàn)

在查看了用戶使用mysql連接測試這一操作的演示，的確存在諸如用戶的描述的現(xiàn)象。如下：

從用戶操作層面，的確存在明顯快慢差別，后者讓人無法接收，“很慢”的確很慢。

問題分析

接下來， 進入信息采集，偵察分析階段。

客戶端抓包分析

在客戶端電腦，分別采集了很快和很慢以上操作的報文信息。結(jié)論如下。

我是很快客戶端的報文

從很快客戶端數(shù)據(jù)看，三步握手后，服務器更新了一下窗口，然后在0.05秒后返回了數(shù)據(jù)庫版本信息。繼而后續(xù)交換較快，整個連接持續(xù)1.2秒時長。

???我是很慢客戶端的報文

下面看一下很慢同學的表現(xiàn)。

同樣，三步握手后，服務器更新了一下窗口信息。

接下來發(fā)生了一個異常現(xiàn)象，服務器在22秒后，才發(fā)送過來版本信息。

整個連接時長約27秒。

通過比較看到，很慢同學的確很慢。相同操作一個是1.2秒，一個是27秒。

服務器端抓包分析

從上述分析看到，很慢同學網(wǎng)絡連接建立時間很快，慢的主要原因是服務器響應回來的信息時間太長。

那么，站著服務器角度，比較分析一下，是否可能由于某些網(wǎng)絡因素導致了很慢的存在。

我是很快服務器的報文

在很快服務器上采集數(shù)據(jù)，從下圖看到，第四個未攜帶數(shù)據(jù)的ack更新窗口包和第五個payload報文（數(shù)據(jù)庫版本信息）之間時間差約0.008秒。

??????我是很慢服務器的報文

同樣，在很慢服務器上，更新窗口包和數(shù)據(jù)庫版本包之間，時間差約22秒。的確很慢。

???? ??抓包分析結(jié)論

通過上述在客戶端和服務器端的對比分析看到，很慢同學慢的原因是，服務器本身發(fā)出報文的時間很長，約22秒。

因此，通過抓包分析的結(jié)論是，很慢的原因是服務器的原因，與網(wǎng)絡無關(guān)。

進一步問題分析

一般情況下，如果是網(wǎng)絡運維部門，問題分析到這里，基本就可以停止了，然后理直氣壯的把球踢給系統(tǒng)部門，哼，這問題不是我的原因。

而網(wǎng)深科技的技術(shù)人員，為了表現(xiàn)出自己的真才實學，帶著打破砂鍋問到底精神，還想進一步探索，為什么會有這種現(xiàn)象出現(xiàn)？

于是，有了進一步問題分析的環(huán)節(jié)。

細節(jié)決定成敗。

在前面服務器抓包分析中，從服務器本身抓包信息來看，服務器本身的IP地址并沒有顯示為數(shù)字格式。與mysql通訊的地址顯示如下。

很快：demo.cloudinside.com.cn.mysql

很慢：Dev1.NAPM.mysql

既然發(fā)現(xiàn)了2者的不同之處，先使用簡單的ping命令，嘗試一下，看看返回結(jié)果。

從最簡單的ping著手，以下是在2臺服務器內(nèi)部ping的結(jié)果。

我是很快服務器的ping

很快同學ping結(jié)果很快出現(xiàn)，名稱解析失敗，結(jié)果是Unknown host，如下圖。

??????我是很慢服務器的ping

很慢同學ping結(jié)果很慢出現(xiàn)，約20秒。結(jié)果是Host name lookup failure，主機名解析失敗。

??????從DNS配置信息入手，下面檢查2臺服務器DNS配置信息。

我是很快服務器的DNS

查看很快服務器DNS，顯示有多個namesever。

???? ?我是很慢服務器的DNS

但很慢服務器的DNS卻沒有配置，如下。

解決問題

通過上述分析，已找到很快和很慢兩者的差異。下一步，嘗試解決問題，通過給很慢配置DNS信息，再做一下ping操作，看看結(jié)果。

很慢服務器配置DNS

為很慢服務器配置DNS信息，內(nèi)容與很快服務器一樣。

如下圖。

????? 很慢服務器ping操作

接下來，再操作一次ping命令。

發(fā)現(xiàn)很快返回信息，結(jié)果和很快服務器一樣，為Unknow host。

????? 問題驗證

通過上述分析和配置后，再次對很慢同學進行mysql連接測試，速度颼颼的，它終于不再飽受埋怨了。

以下是很慢成為了很快的見證。

整個連接時長1.13秒。

問題解決。