某臺「Nginx / PHP」服務(wù)器時不時出現(xiàn)HTTP服務(wù)卡住的現(xiàn)象。

開始我懷疑PHP有問題，但是通過查詢Nginx的access日志，發(fā)現(xiàn)里面記錄的PHP響應(yīng)時間「$upstream_response_time」非常小，此外還通過Strace命令仔細核對了是否存在耗時的操作，結(jié)果一無所獲，所以基本排除了PHP的嫌疑。

接著我把目光轉(zhuǎn)移到了Nginx身上，琢磨著是不是Nagle算法導(dǎo)致的網(wǎng)絡(luò)延遲，不過Nginx缺省就通過「tcp_nodelay」指令關(guān)閉了Nagle算法，所以基本排除了Nginx的嫌疑。

既然Nginx和PHP都有不在場的證據(jù)，那會不會是Linux內(nèi)核參數(shù)的問題呢？因為這臺Web服務(wù)器前面有NAT方式的LVS，所以如果「tcp_timestamps」和「tcp_tw_recycle」等內(nèi)核參數(shù)設(shè)置不當?shù)脑?，會?dǎo)致網(wǎng)絡(luò)故障，可是通過檢查再次否定了這個推斷。

問題到了這里似乎陷入了僵局，看來瞎蒙是沒戲了，只好硬著頭皮用tcpdump了，說硬著頭皮是因為我這個山寨OPS對TCP協(xié)議實在是不熟悉，但是為了解決問題，只能趕鴨子上架了，找一個客戶端重現(xiàn)故障，然后在服務(wù)端監(jiān)聽：

shell> tcpdump -i eth0 host <CLIENTIP> and port 80

不出意外是一大堆天書般的結(jié)果，一句話：法海你不懂愛。好在菜鳥有菜鳥的玩法，祭出神器：Wireshark，可以通過它來可視化分析tcpdump生成的日志文件：

shell> tcpdump -w /path/to/log -i eth0 host <CLIENTIP> and port 80

本例中最終的效果圖大致如下所示：

通過wireshark分析tcpdump結(jié)果

黑色一看就有問題，果斷搜索：TCP Dup ACK，TCP Out-Of-Order，結(jié)果發(fā)現(xiàn)此類問題基本都意味著網(wǎng)絡(luò)狀況不好，推測網(wǎng)絡(luò)可能存在丟包。

如何判斷網(wǎng)絡(luò)是否存在丟包呢？非常簡單，通過常用的「ping」命令即可：

shell> ping -f <IP>

關(guān)于其中的「-f」選項，在手冊中是這樣解釋的：

Flood ping. For every ECHO_REQUEST sent a period “.” is printed, while for ever ECHO_REPLY received a backspace is printed.  This provides a rapid display of how many packets are being dropped. If interval is not given, it sets interval to zero and outputs packets as fast as they come back or one hundred times per second, whichever is more. Only the super-user may use this option with zero interval.

簡單點說：發(fā)送洪水請求，每個請求打印一個點，每個響應(yīng)刪除一個點。如果網(wǎng)絡(luò)存在丟包，那么會呈現(xiàn)出一長串不斷增加的點，簡單易用，童叟無欺。

…

最終確認了網(wǎng)絡(luò)確實存在丟包?？偹阕プ×苏鎯?，對一個山寨的OPS來說，問題分析到這里就算差不多了，至于為什么會丟包的問題，可能是網(wǎng)線的問題，也可能是網(wǎng)卡的問題，還可能是帶寬的問題，等等等等，這些就留給真正的OPS去折騰吧。