轉(zhuǎn)載自?服務(wù)器性能指標(biāo)（一）——負載（Load）分析及問題排查

平常的工作中，在衡量服務(wù)器的性能時，經(jīng)常會涉及到幾個指標(biāo)，load、cpu、mem、qps、rt等。每個指標(biāo)都有其獨特的意義，很多時候在線上出現(xiàn)問題時，往往會伴隨著某些指標(biāo)的異常。大部分情況下，在問題發(fā)生之前，某些指標(biāo)就會提前有異常顯示。

對于這些指標(biāo)的理解和查看、異常解決等，是程序員們重要的必備技能。本文，主要來介紹一下一個比較重要的指標(biāo)——機器負載（Load），主要涉及負載的定義、查看負載方式、負載飆高排查思路等。

什么是負載

負載(load)是linux機器的一個重要指標(biāo)，直觀了反應(yīng)了機器當(dāng)前的狀態(tài)。

來看下負載的定義是怎樣的：

In UNIX computing, the system load is a measure of the amount of computational work that a computer system performs. The load average represents the average system load over a period of time. It conventionally appears in the form of three numbers which represent the system load during the last one-, five-, and fifteen-minute periods.（wikipedia）

簡單解釋一下：在UNIX系統(tǒng)中，系統(tǒng)負載是對當(dāng)前CPU工作量的度量，被定義為特定時間間隔內(nèi)運行隊列中的平均線程數(shù)。load average 表示機器一段時間內(nèi)的平均load。這個值越低越好。負載過高會導(dǎo)致機器無法處理其他請求及操作，甚至導(dǎo)致死機。

Linux的負載高，主要是由于CPU使用、內(nèi)存使用、IO消耗三部分構(gòu)成。任意一項使用過多，都將導(dǎo)致服務(wù)器負載的急劇攀升。

查看機器負載

在Linux機器上，有多個命令都可以查看機器的負載信息。其中包括uptime、top、w等。

uptime命令

uptime命令能夠打印系統(tǒng)總共運行了多長時間和系統(tǒng)的平均負載。uptime命令可以顯示的信息顯示依次為：現(xiàn)在時間、系統(tǒng)已經(jīng)運行了多長時間、目前有多少登陸用戶、系統(tǒng)在過去的1分鐘、5分鐘和15分鐘內(nèi)的平均負載。

? ?~?uptime
13:29??up?23:41, 3?users,?load?averages: 1.74?1.87?1.97

這行信息的后半部分，顯示"load average"，它的意思是"系統(tǒng)的平均負荷"，里面有三個數(shù)字，我們可以從中判斷系統(tǒng)負荷是大還是小。

1.74 1.87 1.97?這三個數(shù)字的意思分別是1分鐘、5分鐘、15分鐘內(nèi)系統(tǒng)的平均負荷。我們一般表示為load1、load5、load15。

w命令

w命令的主要功能其實是顯示目前登入系統(tǒng)的用戶信息。但是與who不同的是，w命令功能更加強大，w命令還可以顯示：當(dāng)前時間，系統(tǒng)啟動到現(xiàn)在的時間，登錄用戶的數(shù)目，系統(tǒng)在最近1分鐘、5分鐘和15分鐘的平均負載。然后是每個用戶的各項數(shù)據(jù)，項目顯示順序如下：登錄帳號、終端名稱、遠 程主機名、登錄時間、空閑時間、JCPU、PCPU、當(dāng)前正在運行進程的命令行。

? ?~?w
14:08??up?23:41, 3?users,?load?averages: 1.74?1.87?1.97
USER?? ??TTY?? ? ?FROM?? ? ? ? ? ? ?LOGIN@ ?IDLE WHAT
hollis ? console ?- ? ? ? ? ? ? ? ?六14???23:40?-
hollis ? s000 ? ? - ? ? ? ? ? ? ? ?六14???20:24?-zsh
hollis ? s001 ? ? - ? ? ? ? ? ? ? ?六15?? ? ? - w

從上面的w命令的結(jié)果可以看到，當(dāng)前系統(tǒng)時間是14:08，系統(tǒng)啟動到現(xiàn)在經(jīng)歷了23小時41分鐘，共有3個用戶登錄。系統(tǒng)在近1分鐘、5分鐘和15分鐘的平均負載分別是1.74 1.87 1.97。這和uptime得到的結(jié)果相同。 下面還打印了一些登錄的用戶的各項數(shù)據(jù)，不詳細介紹了。

top命令

top命令是Linux下常用的性能分析工具，能夠?qū)崟r顯示系統(tǒng)中各個進程的資源占用狀況，類似于Windows的任務(wù)管理器。

? ?~?top
Processes:?244?total,?3?running,?9?stuck,?232?sleeping,?1484?threads
14:16:01?Load?Avg:?1.74,?1.87,?1.97??CPU?usage:?8.0%?user,?6.79%?sys,?85.19%?idle???SharedLibs:?116M?resident,?16M?data,?14M?linkedit.?MemRegions:?66523?total,?2152M?resident,?50M?private,?930M?shared.
PhysMem:?7819M?used?(1692M wired),?370M?unused.?VM:?682G?vsize,?533M?framework?vsize,?6402060(0)?swapins,?7234356(0)?swapouts.?Networks:?packets:?383006/251M?in,?334448/60M?out.
Disks:?1057821/38G?read,?350852/40G?written.

PID?? ?COMMAND?? ? ?%CPU?TIME?? ??#TH???#WQ??#PORT?MEM?? ?PURG???CMPRS??PGRP??PPID??STATE?? ?BOOSTS?? ? ? ? ?%CPU_ME?%CPU_OTHRS?UID??FAULTS?? ?COW?? ?MSGSENT???MSGRECV???SYSBSD?? ?SYSMACH???CSW
30845??top?? ? ? ? ?3.0??00:00.49?1/1???0?? ?21?? ?3632K??0B?? ??0B?? ??30845?1394??running??*0[1]?? ? ? ? ??0.00000?0.00000?? ?0?? ?3283+ ? ??112?? ?203556+ ??101770+ ??8212+ ? ??119901+ ??823+
30842??Google?Chrom?0.0??00:47.39?17?? ?0?? ?155???130M???0B?? ??0B?? ??1146??1146??sleeping?*0[1]?? ? ? ? ??0.00000?0.00000?? ?501??173746?? ?2697???117678?? ?37821?? ??364228?? ?444830?? ?310043

上面的輸出結(jié)果中，Load Avg: 1.74, 1.87, 1.97顯示的就是負載信息。

機器正常負載范圍

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

為什么會有這么多不同的理解呢，是因為不同的機器除了CPU影響之外還有其他因素的影響，運行的程序、機器內(nèi)存、甚至是機房溫度等都有可能有區(qū)別。

比如，有些機器用于定時執(zhí)行大量的跑批任務(wù)，這個時間段內(nèi)，Load可能會飆的比較高。而其他時間可能會比較低。那么這段飆高時間我們要不要去排查問題呢？

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

但是，總要有個建議的閾值吧，關(guān)于這個值。阮一峰在自己的博客中有過以下建議：

當(dāng)系統(tǒng)負荷持續(xù)大于0.7，你必須開始調(diào)查了，問題出在哪里，防止情況惡化。

當(dāng)系統(tǒng)負荷持續(xù)大于1.0，你必須動手尋找解決辦法，把這個值降下來。

當(dāng)系統(tǒng)負荷達到5.0，就表明你的系統(tǒng)有很嚴(yán)重的問題，長時間沒有響應(yīng)，或者接近死機了。你不應(yīng)該讓系統(tǒng)達到這個值。

以上指標(biāo)都是基于單CPU的，但是現(xiàn)在很多電腦都是多核的。所以，對一般的系統(tǒng)來說，是根據(jù)cpu數(shù)量去判斷系統(tǒng)是否已經(jīng)過載（Over Load）的。如果我們認為0.7算是單核機器負載的安全線的話，那么四核機器的負載最好保持在3(4*0.7 = 2.8)以下。

還有一點需要提一下，在Load Avg的指標(biāo)中，有三個值，1分鐘系統(tǒng)負荷、5分鐘系統(tǒng)負荷，15分鐘系統(tǒng)負荷。我們在排查問題的時候也是可以參考這三個值的。

一般情況下，1分鐘系統(tǒng)負荷表示最近的暫時現(xiàn)象。15分鐘系統(tǒng)負荷表示是持續(xù)現(xiàn)象，并非暫時問題。如果load15較高，而load1較低，可以認為情況有所好轉(zhuǎn)。反之，情況可能在惡化。

如何降低負載

導(dǎo)致負載高的原因可能很復(fù)雜，有可能是硬件問題也可能是軟件問題。

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

前面我們提過，CPU使用、內(nèi)存使用、IO消耗都可能導(dǎo)致負載高。如果是軟件問題，有可能由于Java中的某些線程被長時間占用、大量內(nèi)存持續(xù)占用等導(dǎo)致。建議從以下幾個方面排查代碼問題：

1、是否有內(nèi)存泄露導(dǎo)致頻繁GC?

2、是否有死鎖發(fā)生?

3、是否有大字段的讀寫?

4、會不會是數(shù)據(jù)庫操作導(dǎo)致的，排查SQL語句問題。

這里還有個建議，如果發(fā)現(xiàn)線上機器Load飆高，可以考慮先把堆棧內(nèi)存dump下來后，進行重啟，暫時解決問題，然后再考慮回滾和排查問題。

Java Web應(yīng)用Load飆高排查思路

1、使用uptime查看當(dāng)前l(fā)oad，發(fā)現(xiàn)load飆高。

? ?~ uptime
13:29??up?23:41,?3?users, load averages:?10?10?10

2、使用top命令，查看占用CPU較高的進程ID。

? ?~?top
PID?USER?? ? ?PR??NI??VIRT??RES??SHR?S?%CPU?%MEM?? ?TIME+ ?COMMAND
1893?admin?? ? 20 ? 0 7127m?2.6g??38m?S?181.7?32.6??10:20.26?java

發(fā)現(xiàn)PID為1893的進程占用CPU 181%。而且是一個Java進程，基本斷定是軟件問題。

3、使用?top命令，查看具體是哪個線程占用率較高

? ?~?top?-Hp?1893
PID?USER?? ? ?PR??NI??VIRT??RES??SHR?S?%CPU?%MEM?? ?TIME+ ?COMMAND
4519?admin?? ? 20 ? 0 7127m?2.6g??38m?R?18.6?32.6?? 0:40.11?java

4、使用printf命令查看這個線程的16進制

? ?~?printf?%x?4519
11a7

5、使用jstack命令查看當(dāng)前線程正在執(zhí)行的方法。(Java命令學(xué)習(xí)系列（二）——Jstack)

? ?~ jstack?1893?|grep?-A?200?11a7
"thread-5"?#500?daemon prio=10?os_prio=0?tid=0x00007f632314a800 nid=0x11a2 runnable [0x000000005442a000]
java.lang.Thread.State: RUNNABLE
at?sun.misc.URLClassPath$Loader.findResource(URLClassPath.java:684)
at?sun.misc.URLClassPath.findResource(URLClassPath.java:188)
at java.net.URLClassLoader$2.run(URLClassLoader.java:569)
at java.net.URLClassLoader$2.run(URLClassLoader.java:567)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findResource(URLClassLoader.java:566)
at org.hibernate.validator.internal.xml.ValidationXmlParser.getInputStreamForPath(ValidationXmlParser.java:248)
at?com.hollis.test.util.BeanValidator.validate(BeanValidator.java:30)

從上面的線程的棧日志中，可以發(fā)現(xiàn)，當(dāng)前占用CPU較高的線程正在執(zhí)行我代碼的com.hollis.test.util.BeanValidator.validate(BeanValidator.java:30) 類。那么就可以去排查這個類是否用法有問題了。

6、還可以使用jstat(Java命令學(xué)習(xí)系列（四）——jstat)來查看GC情況，看看是否有頻繁FGC，然后再使用jmap(Java命令學(xué)習(xí)系列（三）——Jmap)來dump內(nèi)存，查看是否存在內(nèi)存泄露。

總結(jié)

以上是生活随笔為你收集整理的服务器性能指标（一）——负载（Load）分析及问题排查的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。