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

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

什么是負(fù)載

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

來(lái)看下負(fù)載的定義是怎樣的：

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）

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

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

/proc/loadavgThe first three fields in this file are load average figures giving the number of jobs in the run queue (stateR) or waiting for disk I/O (state D) averaged over 1, 5, and 15 minutes. They are the same as the load averagenumbers given by uptime(1) and other programs. The fourth field consists of two numbers separated by a slash(/). The first of these is the number of currently executing kernel scheduling entities (processes, threads);this will be less than or equal to the number of CPUs. The value after the slash is the number of kernelscheduling entities that currently exist on the system. The fifth field is the PID of the process that was mostrecently created on the system. 這段話大意是說(shuō)，loadavg文件中前三個(gè)字段是平均負(fù)載值，分別代表1、5和15分鐘的作業(yè)(job)數(shù)量的平均值，作業(yè)(job)包括運(yùn)行隊(duì)列(state R)或者等待磁盤(pán)I/O(state D)兩種類(lèi)型。這里面有這么幾層信息：

/proc/loadavg中前三個(gè)數(shù)字分別表示load1、load5、load15的值。

load值代表的是對(duì)應(yīng)時(shí)間內(nèi)的jobs的平均數(shù)量，比如load1就表示過(guò)去1分鐘內(nèi)的jobs數(shù)量的平均值。job主要是一個(gè)shell概念，和進(jìn)程組概念近似，這里應(yīng)該屬于用詞不當(dāng)（后面會(huì)分析，準(zhǔn)確的用詞應(yīng)該是內(nèi)核中的tasks或用戶(hù)空間中的threads概念）。

而且只包含state狀態(tài)為R和D的兩種jobs，其他state狀態(tài)不包含在內(nèi)。

查看機(jī)器負(fù)載。

在Linux機(jī)器上，有多個(gè)命令都可以查看機(jī)器的負(fù)載信息。其中包括uptime、top、w等。

uptime命令

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

? ~ uptime 13:29 up 23:41, 3 users, load averages: 1.74 1.87 1.97 復(fù)制代碼

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

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

w命令

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

? ~ 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 復(fù)制代碼

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

top命令

top命令是Linux下常用的性能分析工具，能夠?qū)崟r(shí)顯示系統(tǒng)中各個(gè)進(jìn)程的資源占用狀況，類(lèi)似于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 復(fù)制代碼

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

機(jī)器正常負(fù)載范圍

對(duì)于機(jī)器的Load到底多少算正常的問(wèn)題，一直都是很有爭(zhēng)議的，不同人有著不同的理解。對(duì)于單個(gè)CPU，有人認(rèn)為如果Load超過(guò)0.7就算是超出正常范圍了。也有人認(rèn)為只要不超過(guò)1都沒(méi)問(wèn)題。也有人認(rèn)為，單個(gè)CPU的負(fù)載在2以下都可以接受。

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

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

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

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

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

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

當(dāng)系統(tǒng)負(fù)荷達(dá)到5.0，就表明你的系統(tǒng)有很?chē)?yán)重的問(wèn)題，長(zhǎng)時(shí)間沒(méi)有響應(yīng)，或者接近死機(jī)了。你不應(yīng)該讓系統(tǒng)達(dá)到這個(gè)值。

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

還有一點(diǎn)需要提一下，在Load Avg的指標(biāo)中，有三個(gè)值，1分鐘系統(tǒng)負(fù)荷、5分鐘系統(tǒng)負(fù)荷，15分鐘系統(tǒng)負(fù)荷。我們?cè)谂挪閱?wèn)題的時(shí)候也是可以參考這三個(gè)值的。

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

如何降低負(fù)載

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

如果是硬件問(wèn)題，那么說(shuō)明機(jī)器性能確實(shí)就不行了，那么解決起來(lái)很簡(jiǎn)單，直接換機(jī)器就可以了。

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

1、是否有內(nèi)存泄露導(dǎo)致頻繁GC 2、是否有死鎖發(fā)生 3、是否有大字段的讀寫(xiě) 4、會(huì)不會(huì)是數(shù)據(jù)庫(kù)操作導(dǎo)致的，排查SQL語(yǔ)句問(wèn)題。5、死循環(huán)

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

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 復(fù)制代碼

2、使用top命令，查看占用CPU較高的進(jìn)程ID。

? ~ topPID 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ù)制代碼

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

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

? ~ 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 復(fù)制代碼

4、使用printf命令查看這個(gè)線程的16進(jìn)制

? ~ printf %x 4519 11a7 復(fù)制代碼

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ù)制代碼

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

分析Linux Load高時(shí)的一個(gè)誤區(qū)

區(qū)分了R和D狀態(tài)線程對(duì)Linux load的影響，我們?cè)賮?lái)看一個(gè)絕大多數(shù)人都曾經(jīng)歷的誤區(qū)。當(dāng)linux系統(tǒng)load標(biāo)高時(shí)，很多人都會(huì)去top一下，查看當(dāng)前系統(tǒng)誰(shuí)占用的CPU Usage最高。

• ??這里補(bǔ)充一個(gè)背景知識(shí)，只有當(dāng)進(jìn)程（線程）處于R狀態(tài)時(shí)，才耗費(fèi)CPU Usage，其他狀態(tài)（包括D狀態(tài)）并不耗費(fèi)CPU Usage。當(dāng)load高主要是由D狀態(tài)線程數(shù)量過(guò)多導(dǎo)致的時(shí)候，此時(shí)從top中按CPU Usage的排名是不會(huì)發(fā)現(xiàn)任何線索的。
• ??即使當(dāng)load高是由R狀態(tài)線程數(shù)量過(guò)多導(dǎo)致，如果運(yùn)行top命令時(shí)導(dǎo)致load高的R狀態(tài)線程已經(jīng)結(jié)束，此時(shí)也不會(huì)從按CPU Usage的排名的top輸出中發(fā)現(xiàn)線索的。默認(rèn)情況下，top命令是3秒中刷新，只顯示3秒內(nèi)的CPU Usage信息。

作者：Hollis_公眾號(hào)Hollis
鏈接：https://juejin.im/post/5b0262edf265da0b9b079fa7
來(lái)源：掘金
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。

新人創(chuàng)作打卡挑戰(zhàn)賽發(fā)博客就能抽獎(jiǎng)！定制產(chǎn)品紅包拿不停！

總結(jié)

以上是生活随笔為你收集整理的负载（Load）分析及问题排查的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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