|
標(biāo)簽：聯(lián)想服務(wù)器，
平常的工作中，在衡量服務(wù)器的性能時(shí)，經(jīng)常會(huì)涉及到幾個(gè)指標(biāo)，load、cpu、mem、qps、rt等。每個(gè)指標(biāo)都有其獨(dú)特的意義，很多時(shí)候在線上出現(xiàn)問題時(shí)，往往會(huì)伴隨著某些指標(biāo)的異常。大部分情況下，在問題發(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ù)載過高會(huì)導(dǎo)致機(jī)器無(wú)法處理其他請(qǐng)求及操作，甚至導(dǎo)致死機(jī)。
Linux的負(fù)載高，主要是由于CPU使用、內(nèi)存使用、IO消耗三部分構(gòu)成。任意一項(xiàng)使用過多，都將導(dǎo)致服務(wù)器負(fù)載的急劇攀升。
查看機(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í)間、目前有多少登陸用戶、系統(tǒng)在過去的1分鐘、5分鐘和15分鐘內(nèi)的平均負(fù)載。
? ~ uptime 13:29 up 23:41, 3 users, load averages: 1.74 1.87 1.97
這行信息的后半部分，顯示"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)的用戶信息。但是與who不同的是，w命令功能更加強(qiáng)大，w命令還可以顯示：當(dāng)前時(shí)間，系統(tǒng)啟動(dòng)到現(xiàn)在的時(shí)間，登錄用戶的數(shù)目，系統(tǒng)在最近1分鐘、5分鐘和15分鐘的平均負(fù)載。然后是每個(gè)用戶的各項(xiàng)數(shù)據(jù)，項(xiàng)目顯示順序如下：登錄帳號(hào)、終端名稱、遠(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
從上面的w命令的結(jié)果可以看到，當(dāng)前系統(tǒng)時(shí)間是14:08，系統(tǒng)啟動(dòng)到現(xiàn)在經(jīng)歷了23小時(shí)41分鐘，共有3個(gè)用戶登錄。系統(tǒng)在近1分鐘、5分鐘和15分鐘的平均負(fù)載分別是1.74 1.87 1.97。這和uptime得到的結(jié)果相同。 下面還打印了一些登錄的用戶的各項(xiàng)數(shù)據(jù)，不詳細(xì)介紹了。
top命令
top命令是Linux下常用的性能分析工具，能夠?qū)崟r(shí)顯示系統(tǒng)中各個(gè)進(jìn)程的資源占用狀況，類似于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顯示的就是負(fù)載信息。
機(jī)器正常負(fù)載范圍
對(duì)于機(jī)器的Load到底多少算正常的問題，一直都是很有爭(zhēng)議的，不同人有著不同的理解。對(duì)于單個(gè)CPU，有人認(rèn)為如果Load超過0.7就算是超出正常范圍了。也有人認(rèn)為只要不超過1都沒問題。也有人認(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í)間我們要不要去排查問題呢?
我的建議是，最好根據(jù)自己機(jī)器的實(shí)際情況，建立一個(gè)指標(biāo)的基線(如近一個(gè)月的平均值)，只要日常的load在基線上下范圍內(nèi)不太大都可以接收，如果差距太多可能就要人為介入檢查了。
但是，總要有個(gè)建議的閾值吧，關(guān)于這個(gè)值。阮一峰在自己的博客中有過以下建議：
當(dāng)系統(tǒng)負(fù)荷持續(xù)大于0.7，你必須開始調(diào)查了，問題出在哪里，防止情況惡化。
當(dāng)系統(tǒng)負(fù)荷持續(xù)大于1.0，你必須動(dòng)手尋找解決辦法，把這個(gè)值降下來(lái)。
當(dāng)系統(tǒng)負(fù)荷達(dá)到5.0，就表明你的系統(tǒng)有很嚴(yán)重的問題，長(zhǎng)時(shí)間沒有響應(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)過載(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è)谂挪閱栴}的時(shí)候也是可以參考這三個(gè)值的。
一般情況下，1分鐘系統(tǒng)負(fù)荷表示最近的暫時(shí)現(xiàn)象。15分鐘系統(tǒng)負(fù)荷表示是持續(xù)現(xiàn)象，并非暫時(shí)問題。如果load15較高，而load1較低，可以認(rèn)為情況有所好轉(zhuǎn)。反之，情況可能在惡化。
如何降低負(fù)載
導(dǎo)致負(fù)載高的原因可能很復(fù)雜，有可能是硬件問題也可能是軟件問題。
如果是硬件問題，那么說(shuō)明機(jī)器性能確實(shí)就不行了，那么解決起來(lái)很簡(jiǎn)單，直接換機(jī)器就可以了。
前面我們提過，CPU使用、內(nèi)存使用、IO消耗都可能導(dǎo)致負(fù)載高。如果是軟件問題，有可能由于Java中的某些線程被長(zhǎng)時(shí)間占用、大量?jī)?nèi)存持續(xù)占用等導(dǎo)致。建議從以下幾個(gè)方面排查代碼問題：
1、是否有內(nèi)存泄露導(dǎo)致頻繁GC
2、是否有死鎖發(fā)生
3、是否有大字段的讀寫
4、會(huì)不會(huì)是數(shù)據(jù)庫(kù)操作導(dǎo)致的，排查SQL語(yǔ)句問題。
這里還有個(gè)建議，如果發(fā)現(xiàn)線上機(jī)器Load飆高，可以考慮先把堆棧內(nèi)存dump下來(lái)后，進(jìn)行重啟，暫時(shí)解決問題，然后再考慮回滾和排查問題。
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較高的進(jìn)程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的進(jìn)程占用CPU 181%。而且是一個(gè)Java進(jì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
4、使用printf命令查看這個(gè)線程的16進(jìn)制
? ~ 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) 類。那么就可以去排查這個(gè)類是否用法有問題了。
6、還可以使用jstat(Java命令學(xué)習(xí)系列(四)——jstat)來(lái)查看GC情況，看看是否有頻繁FGC，然后再使用jmap(Java命令學(xué)習(xí)系列(三)——Jmap)來(lái)dump內(nèi)存，查看是否存在內(nèi)存泄露。
|
