一些Linux系統服務調優/問題定位技巧

文章目錄

• 調優 - 伺服器記憶體“吃”swap的問題
• 調優 - 系統比較
• 服務問題（慢、卡、宕機）定位
• 網路問題（慢、卡）定位
• 雜題 – FireFox瀏覽器連線逾時
• 雜題 – IRQ Affinity

調優 - 伺服器記憶體“吃”swap的問題

swap記憶體當然會慢點，所以我們必須想盡辦法盡量別用它。即使設定系統參數 vm.swappiness = 0 ，系統也會使用swap，而且測試中發現，swap的使用與Java服務進程沒有必然聯絡，即使不起任何Java進程，swap也會被使用。

所以 vm.swappniess 參數的值只是告訴系統要“積極地”使用swap（設為100），還是“盡量別”使用swap（設為0）。
一般資料庫伺服器，需要將 vm.swappniess 參數設定成 0，以獲得流暢的資料讀寫。

如果能“確保”系統不使用任何swap，可以使用如下命令真正關閉系統的swap記憶體：

swapoff -a

當然，需要反覆使用如下命令“確保”swap真的不需要使用：

free –mt

原則就是：Mem:total 始終大於 Total:used，你要“確保”這個條件總是成立。通過編寫一個指令碼在伺服器上反覆執行一段時間是驗證這個原則的辦法。

謹慎：關閉swap就會產生嚴重後果——如果記憶體消耗完畢，系統很可能崩潰。

調優 - 系統比較

配置差不多的伺服器，啟動並執行服務相同，效果一個好一個差，那麼就可以考慮比較系統上的進程和參數了：
分別執行 ps –ef / sysctl –a ，比較兩台伺服器上的 進程 / 系統配置，看看有何不同？
另外，ps auxf 可以顯示父子進程的樹狀關係，ps –eLF 可以顯示到線程。

服務問題（慢、卡、宕機）定位

檢查系統：TCP串連，記憶體，CPU負載，IO的資訊。

檢查前端代理服務的訪問日誌（例如：access.log）可以分析集中訪問攻擊和請求分布的問題。例如：有的頁面出現了問題，使用者可能會瘋狂的刷頁面的URL，導致此URI的請求短時間內暴增。

檢查應用伺服器標準輸出日誌（例如：stdout.log）裡串連數滿等情況。應用伺服器並發串連數是有上限的，例如Resin企業版：

    ……
    [05:08:48.687][05:08:48.687] WebApp[ http://localhost:8080]
stopping
    [05:09:03.375][05:09:03.375] WebApp[ http://localhost:8080]
closing with 512 active requests.
    ……

檢查應用伺服器標準錯誤輸出日誌（例如：stderr.log），在這裡面發現的問題應該是很明顯的。

檢查應用程式的日誌（包括業務日誌），在這裡能否發現問題取決於應用程式的日誌架構設計了。如果程式員把異常都“吃”了，那麼神仙也查不出問題了——除非查代碼。

如果以上都查不出問題，那就上工具。拿JavaEE應用程式來說，JDK內建的jmap可以查記憶體流失、jstack可以查線程阻塞（線程可能被資料庫慢查詢、頻繁打日誌造成的IO繁忙、線程對象死結等問題阻塞）、jstat可以查GC情況（這可以指導你調整JVM啟動參數）。

如果還查不出問題，那麼可以考慮人肉查代碼了……

網路問題（慢、卡）定位

看網路品質
。使用ping命令，參數 -l 指定包大小，-n 指定包數，-f 洪水發包，看丟包情況，瞭解網路品質。

看路由資訊
。例如：mtr -r --c www.baidu.com 或 traceroute
-n www.baidu.com
，一看便知。

看Socket統計資訊
。ss -s：
Total: 215 (kernel 216)
TCP:   159 (estab 115, closed 21, orphaned 0, synrecv 0, timewait 9/0), ports 72

Transport Total     IP        IPv6
*         216       -         -       
RAW       0         0         0       
UDP       11        11        0       
TCP       138       138       0       
INET      149       149       0       
FRAG      0         0         0 

看開啟的網路連接埠
。ss -l。

看進程開啟的網路連接埠
。ss –pl。

看抓包
。tcpdump，分析網路抓包是個精細活……

看用戶端Http請求回放
。建立服務端：nc –l 8888，然後要求用戶端訪問：http://(serverhost):8888
。即可在服務端收到用戶端的Http請求，分析其要求標頭資訊，可以發現用戶端的問題——很多時候服務端是被冤枉的

雜題 – FireFox瀏覽器連線逾時

在首次串連或者閑置一段時間後重新串連總是出現問題。

只在集中訪問本站的公司內部網路中出現問題。

定位：區域網路內有很多使用者同時訪問，會出現首次串連伺服器逾時。

這個問題是由於系統的 tcp_tw_recycle 參數設定為1造成的。執行：sysctl net.ipv4.tcp_tw_recycle=0，即可。

雜題 – IRQ Affinity

在多CPU伺服器上執行 top ，然後輸入 1 ，發現不是所有的CPU在扛負載，那麼服務很可能會由於負載過高受到影響。

定位：有可能伺服器在執行 IRQ Affinity ——綁定特定的硬體中斷到特定的CPU上，分散和平衡各個中斷到不同的CPU上以擷取更大效能的處理能力。

重新啟動系統服務 IRQBalance 和應用服務即可。IRQBalance是個用來自動綁定和平衡IRQ 的系統服務。