伺服器負載分析

導讀	平常的工作中，在衡量伺服器的效能時，經常會涉及到幾個指標，load、cpu、mem、qps、rt等。每個指標都有其獨特的意義，很多時候線上上出現問題時，往往會伴隨著某些指標的異常。大部分情況下，在問題發生之前，某些指標就會提前有異常顯示。

平常的工作中，在衡量伺服器的效能時，經常會涉及到幾個指標，load、cpu、mem、qps、rt等。每個指標都有其獨特的意義，很多時候線上上出現問題時，往往會伴隨著某些指標的異常。大部分情況下，在問題發生之前，某些指標就會提前有異常顯示。

對於這些指標的理解和檢視、異常解決等，是程式設計師們重要的必備技能。本文，主要來介紹一下一個比較重要的指標——機器負載(Load)，主要涉及負載的定義、檢視負載方式、負載飆高排查思路等。

隨著 Internet 的快速發展和業務量的不斷提高，基於網路的資料訪問流量迅速增長，特別是對資料 中心、大型企業以及入口網站等的訪問，其訪問流量甚至達到了 10Gb/s 的級別;同時，伺服器網 站藉助 HTTP、FTP、SMTP 等應用程式，為訪問者提供了越來越豐富的內容和資訊，伺服器逐漸 被資料淹沒;另外，大部分網站(尤其電子商務等網站)都需要提供不間斷 24 小時服務，任何服 務中斷或通訊中的關鍵資料丟失都會造成直接的商業損失。所有這些都對應用服務提出了高效能和 高可靠性的需求，這些海量的訪問資料均是負載。

在 機器上，有多個 都可以檢視機器的負載資訊。其中包括uptime 、top、w 等。

命令能夠列印系統總共執行了多長時間和系統的平均負載。uptime命令可以顯示的資訊顯示依次為：現在時間、系統已經執行了多長時間、目前有多少登陸使用者、系統在過去的1分鐘、5分鐘和15分鐘內的平均負載。

➜ ~uptime13:29 up23:41, 3users,loadaverages: 1.741.871.97

這行資訊的後半部分，顯示"load average"，它的意思是"系統的平均負荷"，裡面有三個數字，我們可以從中判斷系統負荷是大還是小。

1.74 1.87 1.97 這三個數字的意思分別是1分鐘、5分鐘、15分鐘內系統的平均負荷。我們一般表示為load1、load5、load15。

w命令的主要功能其實是顯示目前登入系統的使用者資訊。但是與who不同的是，w命令功能更加強大，w命令還可以顯示：當前時間，系統啟動到現在的時間，登入使用者的數目，系統在最近1分鐘、5分鐘和15分鐘的平均負載。然後是每個使用者的各項資料，專案顯示順序如下：登入帳號、終端名稱、遠 程主機名、登入時間、空閒時間、JCPU、PCPU、當前正在執行程式的命令列。

➜ ~w14:08 up23:41, 3users,loadaverages: 1.741.871.97USER TTY FROM LOGIN@ IDLE WHAThollis console - 六14 23:40-hollis s000 - 六14 20:24-zshhollis s001 - 六15 - w

從上面的w命令的結果可以看到，當前系統時間是14:08，系統啟動到現在經歷了23小時41分鐘，共有3個使用者登入。系統在近1分鐘、5分鐘和15分鐘的平均負載分別是1.74 1.87 1.97。這和uptime得到的結果相同。 下面還列印了一些登入的使用者的各項資料，不詳細介紹了。

top命令是Linux下常用的效能分析工具，能夠實時顯示系統中各個程式的資源佔用狀況，類似於Windows的工作管理員。

➜ ~topProcesses:244total,3running,9stuck,232sleeping,1484threads14:16:01LoadAvg:1.74,1.87,1.97 CPUusage:8.0%user,6.79%sys,85.19%idle SharedLibs:116Mresident,16Mdata,14Mlinkedit.MemRegions:66523total,2152Mresident,50Mprivate,930Mshared.PhysMem:7819Mused(1692M wired),370Munused.VM:682Gvsize,533Mframeworkvsize,6402060(0)swapins,7234356(0)swapouts.Networks:packets:383006/251Min,334448/60Mout.Disks:1057821/38Gread,350852/40Gwritten.PID COMMAND %CPUTIME #TH #WQ #PORTMEM PURG CMPRS PGRP PPID STATE BOOSTS %CPU_ME%CPU_OTHRSUID FAULTS COW MSGSENT MSGRECV SYSBSD SYSMACH CSW30845 top 3.0 00:00.491/1 0 21 3632K 0B 0B 308451394 running *0[1] 0.000000.00000 0 3283+ 112 203556+ 101770+ 8212+ 119901+ 823+30842 GoogleChrom0.0 00:47.3917 0 155 130M 0B 0B 1146 1146 sleeping*0[1] 0.000000.00000 501 173746 2697 117678 37821 364228 444830 310043

上面的輸出結果中，Load Avg: 1.74, 1.87, 1.97顯示的就是負載資訊。

對於機器的Load到底多少算正常的問題，一直都是很有爭議的，不同人有著不同的理解。對於單個CPU，有人認為如果Load超過0.7就算是超出正常範圍了。也有人認為只要不超過1都沒問題。也有人認為，單個CPU的負載在2以下都可以接受。

為什麼會有這麼多不同的理解呢，是因為不同的機器除了CPU影響之外還有其他因素的影響，執行的程式、機器記憶體、甚至是機房溫度等都有可能有區別。

比如，有些機器用於定時執行大量的跑批任務，這個時間段內，Load可能會飆的比較高。而其他時間可能會比較低。那麼這段飆高時間我們要不要去排查問題呢?

我的建議是，最好根據自己機器的實際情況，建立一個指標的基線(如近一個月的平均值)，只要日常的load在基線上下範圍內不太大都可以接收，如果差距太多可能就要人為介入檢查了。

導致負載高的原因可能很複雜，有可能是硬體問題也可能是軟體問題。

如果是硬體問題，那麼說明機器效能確實就不行了，那麼解決起來很簡單，直接換機器就可以了。

前面我們提過，CPU使用、記憶體使用、IO消耗都可能導致負載高。如果是軟體問題，有可能由於Java中的某些執行緒被長時間佔用、大量記憶體持續佔用等導致。建議從以下幾個方面排查程式碼問題：

1. 1、是否有記憶體洩露導致頻繁GC

1. 2、是否有死鎖發生

1. 3、是否有大欄位的讀寫

1. 4、會不會是資料庫操作導致的，排查SQL語句問題。

這裡還有個建議，如果發現線上機器Load飆高，可以考慮先把堆疊記憶體dump下來後，進行重啟，暫時解決問題，然後再考慮回滾和排查問題。

1、使用uptime檢視當前load，發現load飆高。

2、使用top命令，檢視佔用CPU較高的程式ID。

3、使用 top命令，檢視具體是哪個執行緒佔用率較高

4、使用printf 命令檢視這個執行緒的16進位制

5、還可以使用jstat()來檢視GC情況，看看是否有頻繁FGC，然後再使用jmap來dump記憶體，檢視是否存在記憶體洩露。

原文來自：