在平時(shí)開發(fā)過程中，對于線上問題的排查以及系統(tǒng)的優(yōu)化，免不了和Linux進(jìn)行打交道。每逢大促和雙十一，對系統(tǒng)的各種壓測性能測試，優(yōu)化都是非常大的一次考驗(yàn)。抽空整理了一下自己在線上問題排查以及系統(tǒng)優(yōu)化的一些經(jīng)驗(yàn)。

一、系統(tǒng)性能瓶頸在哪

我們常常提到項(xiàng)目的運(yùn)行環(huán)境，那么運(yùn)行環(huán)境包括哪些呢？一般包括你的操作系統(tǒng)、CPU、內(nèi)存、硬盤、網(wǎng)絡(luò)帶寬、JRE環(huán)境、你的代碼依賴的各種組件等等。所以系統(tǒng)性能的瓶頸往往是IO瓶頸、CPU瓶頸、內(nèi)存瓶頸或者程序?qū)е碌男阅芷款i

登錄到服務(wù)器上，我們使用TOP命令可以很全面的看到系統(tǒng)資源使用情況

CPU瓶頸如何分析

使用TOP命令，輸入大寫P（即shift + P）可以按照CPU使用大小降序排序，在TOP命令第三行可以看到關(guān)鍵信息 %id：空閑CPU時(shí)間百分比，如果這個(gè)值過低，表明系統(tǒng)CPU存在瓶頸。如果過低，一般都是你的java程序?qū)е碌模孕枰卿浀絛ocker容器通過jstack命令查看堆棧信息來分析原因

確認(rèn)目標(biāo)進(jìn)程

查看對應(yīng)進(jìn)程信息 -> 登錄容器查看容器id -> 進(jìn)入容器 -> 容器內(nèi)top命令查看CPU過高的目標(biāo)進(jìn)程

#top
#ps -ef | grep 進(jìn)程號
#sudo docker ps -a
#sudo docker exec -it 容器id bash
#top

對于CPU使用情況詳細(xì)信息可以使用sar命令；命令中1 3 表示每秒采樣1次，一共采樣3次

#sar -u 1 3

打印堆棧信息

由于進(jìn)程是admin用戶啟動(dòng)的，所以jstack打印堆棧信息需要切換admin用戶，確保你的機(jī)器上裝了jstack命令;

然后退出容器，將文件復(fù)制移動(dòng)到個(gè)人家目錄（如果cp命令不能使用，可以通過scp命令移動(dòng)到個(gè)人家目錄）

通過sftp命令將文件copy到本地機(jī)器上，來分析堆棧日志信息；如果裝了sz命令，或者通過sz命令下載也可以

# sudo -u admin /opt/usr/java/bin/jstack -l 76 > /home/admin/test/logs/jstack.log
# cp /home/admin/test/logs/jstack.log ~/

分析堆棧信息

進(jìn)入容器，查看哪些線程占比高（截圖只是為了說明如何使用，實(shí)際cpu并沒有很高）

#top -H p 進(jìn)程id

將占比高的線程PID換算成16進(jìn)制，去堆棧日志找對應(yīng)的線程堆棧信息，分析問題就可以了

內(nèi)存瓶頸如何分析

項(xiàng)目開發(fā)過程中，線程的不合理使用或者集合的不合理使用，通常會(huì)導(dǎo)致內(nèi)存oom情況，對于內(nèi)存瓶頸一般通過top命令查看，或者free命令查看內(nèi)存使用情況;更詳細(xì)可以通過vmstat命令查看

free命令，實(shí)際可用內(nèi)存為free + buff + available;

#free -m

如何分析內(nèi)存使用，找到內(nèi)存過高的原因呢，需要登錄到docker容器中查看內(nèi)存占比比較高的進(jìn)程，通過jmap命令dump下來，通過IBM的分析工具M(jìn)A來分析

確定目標(biāo)進(jìn)程 -> jmap -> 通過scp命令copy到個(gè)人家目錄 -> 由于dump文件比較大，所以下載到本地之前通過tar命令壓縮一下

#sudo -u admin /opt/usr/java/bin/jmap -dump:live,format=b,file=/home/admin/test/logs/java.heap.bin 進(jìn)程號
#scp 用戶名@host:/home/admin/test/logs/java.heap.bin ~/
#cd ~
#tar -zcvf java.heap.bin.tar.gz java.heap.bin

一般內(nèi)存分析查看最多的就是Actions下面的Histogram，查看對象引用有多少?zèng)]有GC；一般正常一個(gè)dump文件看起來不明顯，需要多個(gè)dump文件對比來查看內(nèi)存泄露的原因

IO瓶頸如何分析

如果IO存在性能瓶頸，top工具中的%wa會(huì)偏高，進(jìn)一步分析用iostat命令工具分析

#iostat -d -k -x 1 1

• 如果%iowait的值過高，表示硬盤存在I/O瓶頸。
• 如果 %util 接近 100%，說明產(chǎn)生的I/O請求太多，I/O系統(tǒng)已經(jīng)滿負(fù)荷，該磁盤可能存在瓶頸。
• 如果 svctm 比較接近 await，說明 I/O 幾乎沒有等待時(shí)間；
• 如果 await 遠(yuǎn)大于 svctm，說明I/O 隊(duì)列太長，io響應(yīng)太慢，則需要進(jìn)行必要優(yōu)化。
• 如果avgqu-sz比較大，也表示有大量io在等待

解決這種問題一般方法有：使用緩存，講述磁盤IO；同步轉(zhuǎn)化成異步、隨機(jī)寫轉(zhuǎn)化成順序?qū)?、替換硬件

調(diào)用第三方接口網(wǎng)絡(luò)報(bào)文分析

項(xiàng)目中有時(shí)候會(huì)遇到第三方接口的服務(wù)調(diào)用，一般通過HTTP客戶端請求，對于常見的服務(wù)連接超時(shí)、系統(tǒng)抖動(dòng)等問題經(jīng)常遇到；這種問題有時(shí)候排查起來比較麻煩，只有通過tcpdump來抓取網(wǎng)絡(luò)層的報(bào)文，在通過wireshark工具來分析原因；對于HTTS協(xié)議的，只能依賴第三方服務(wù)端抓包來分析

#tcpdump -i eth0 dst host hostname -C 10240 -W 50 -w xx.cap

一般需要root用戶權(quán)限，hostname替換成實(shí)際主機(jī)ip或域名，eth0是網(wǎng)卡，一般服務(wù)器會(huì)有多個(gè)網(wǎng)卡，所以一定要指定抓取哪個(gè)網(wǎng)卡上對應(yīng)的網(wǎng)絡(luò)數(shù)據(jù)報(bào)文

我們來回顧一下在傳輸層TCP三次握手和四次揮手的過程
客戶端和服務(wù)端進(jìn)行數(shù)據(jù)傳輸一般都是HTTP或者HTTPS協(xié)議，HTTP超文本傳輸協(xié)議是建議在TCP傳輸協(xié)議上進(jìn)行傳輸數(shù)據(jù)的，底層TCP傳輸通過套接字Socket進(jìn)行數(shù)據(jù)流傳輸；至于為什么是三次握手，可以理解為信道不可靠，傳輸要可靠，三次握手是理論上的最小值

第一次握手：建立連接?？蛻舳税l(fā)送連接請求報(bào)文段，將SYN位置為1，Sequence Number為x；然后，客戶端進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器的確認(rèn)；

第二次握手：服務(wù)器收到SYN報(bào)文段。服務(wù)器收到客戶端的SYN報(bào)文段，需要對這個(gè)SYN報(bào)文段進(jìn)行確認(rèn)，設(shè)置Acknowledgment Number為x+1(Sequence Number+1)；同時(shí)，自己自己還要發(fā)送SYN請求信息，將SYN位置為1，Sequence Number為y；服務(wù)器端將上述所有信息放到一個(gè)報(bào)文段（即SYN+ACK報(bào)文段）中，一并發(fā)送給客戶端，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)；

第三次握手：客戶端收到服務(wù)器的SYN+ACK報(bào)文段。然后將Acknowledgment Number設(shè)置為y+1，向服務(wù)器發(fā)送ACK報(bào)文段，這個(gè)報(bào)文段發(fā)送完畢以后，客戶端和服務(wù)器端都進(jìn)入ESTABLISHED狀態(tài)，完成TCP三次握手。
完成了三次握手，客戶端和服務(wù)器端就可以開始傳送數(shù)據(jù)。以上就是TCP三次握手的總體介紹

那四次分手呢？

當(dāng)客戶端和服務(wù)器通過三次握手建立了TCP連接以后，當(dāng)數(shù)據(jù)傳送完畢，肯定是要斷開TCP連接的啊。那對于TCP的斷開連接，這里就有了神秘的“四次分手”。

第一次分手：主機(jī)1（可以使客戶端，也可以是服務(wù)器端），設(shè)置Sequence Number和Acknowledgment Number，向主機(jī)2發(fā)送一個(gè)FIN報(bào)文段；此時(shí)，主機(jī)1進(jìn)入FIN_WAIT_1狀態(tài)；這表示主機(jī)1沒有數(shù)據(jù)要發(fā)送給主機(jī)2了；

第二次分手：主機(jī)2收到了主機(jī)1發(fā)送的FIN報(bào)文段，向主機(jī)1回一個(gè)ACK報(bào)文段，Acknowledgment Number為Sequence Number加1；主機(jī)1進(jìn)入FIN_WAIT_2狀態(tài)；主機(jī)2告訴主機(jī)1，我“同意”你的關(guān)閉請求；

第三次分手：主機(jī)2向主機(jī)1發(fā)送FIN報(bào)文段，請求關(guān)閉連接，同時(shí)主機(jī)2進(jìn)入LAST_ACK狀態(tài)；

第四次分手：主機(jī)1收到主機(jī)2發(fā)送的FIN報(bào)文段，向主機(jī)2發(fā)送ACK報(bào)文段，然后主機(jī)1進(jìn)入TIME_WAIT狀態(tài)；主機(jī)2收到主機(jī)1的ACK報(bào)文段以后，就關(guān)閉連接；此時(shí)，主機(jī)1等待2MSL后依然沒有收到回復(fù)，則證明Server端已正常關(guān)閉，那好，主機(jī)1也可以關(guān)閉連接了。

追蹤online應(yīng)用java動(dòng)態(tài)運(yùn)行細(xì)節(jié)

對于online應(yīng)用，有時(shí)候需要關(guān)注java運(yùn)行時(shí)的一些細(xì)節(jié)，可以通過Btrace命令跟蹤

https://legacy.gitbook.com/book/json-liu/btrace/details

二、項(xiàng)目代碼常見問題排查

在講述這個(gè)問題之前，有必要聊一下java的類加載機(jī)制以及JVM內(nèi)存結(jié)構(gòu)，理解了這些，對于我們常見的OOM問題、性能調(diào)優(yōu)會(huì)帶來很大幫助

類加載機(jī)制

類加載虛擬機(jī)內(nèi)存到最終卸載是有一個(gè)完整的生命周期的，它的整個(gè)生命周期包括：加載、驗(yàn)證、準(zhǔn)備、解析、初始化、使用和卸載七個(gè)階段

類加載過程，類加載器采用的是雙親委派原則，首先是啟動(dòng)類加載器BootStrap加載，然后是擴(kuò)展類加載器、應(yīng)用程序加載器、

自定義類加載器

驗(yàn)證：通過對class文件的類全名通過getResourceAsStream轉(zhuǎn)化成二進(jìn)制流，然后將靜態(tài)的數(shù)據(jù)結(jié)構(gòu)（構(gòu)造函數(shù)、屬性、方法等）轉(zhuǎn)化成運(yùn)行時(shí)方法區(qū)的數(shù)據(jù)結(jié)構(gòu)

驗(yàn)證主要有class文件格式校驗(yàn)（class文件是否以一些非法字符開頭）、元數(shù)據(jù)信息校驗(yàn)（比如java類是否有父類，父類是否被final修飾符修飾等等）、字節(jié)碼驗(yàn)證（對類的方法進(jìn)行驗(yàn)證）、符號引用驗(yàn)證（通過全限定名能否找到對應(yīng)的類）

準(zhǔn)備：就是對類進(jìn)行分配內(nèi)存、對變量進(jìn)行初始化賦值 public static int = 123 賦值為0 還不是123 因?yàn)?putstatic指令存在類構(gòu)造器方法中，只有在初始化階段賦值為123

解析：類、接口、方法解析，主要是將符號引用替換為直接引用，符號引用java虛擬機(jī)內(nèi)存引用無關(guān)，直接引用可以是指針位置，偏移量可以具體定位到內(nèi)存具體位置的

初始化：對變量進(jìn)行賦值，putstatic getstatic、invokestatic指令，《clinit》構(gòu)造方法中，進(jìn)行賦值

JVM內(nèi)存結(jié)構(gòu)

java虛擬機(jī)在執(zhí)行java代碼的時(shí)候，會(huì)把它所管理的內(nèi)存劃分不同的區(qū)域，JVM內(nèi)存的劃分結(jié)構(gòu)如下：

其中方法區(qū)和堆區(qū)是所有線程共享的區(qū)域，虛擬機(jī)棧、本地方法棧、程序計(jì)數(shù)器是線程私有

在這幾個(gè)區(qū)域中，除了程序計(jì)數(shù)器不會(huì)產(chǎn)生oom問題，其他區(qū)域都有可能產(chǎn)生oom

堆區(qū)

java heap是JVM內(nèi)存最大的一塊區(qū)域，幾乎所有的java實(shí)例以及數(shù)組分配都在這里完成，根據(jù)內(nèi)存的回收算法，可以將堆區(qū)劃分年輕代和老年代，比例為1:2的關(guān)系，其中年輕代又分為Eden和2個(gè)survival區(qū)，為8:1:1的關(guān)系；在這個(gè)區(qū)域最容易發(fā)生oom，一般原因有2種可能，流量峰值超過程序設(shè)定的閾值或者內(nèi)存泄露；比如內(nèi)存泄露最常見的就是集合局部變量，由于使用不得當(dāng)，一直無法GC，就會(huì)觸發(fā)java.lang.OutOfMemoryError；

回顧一下年輕代和老年代的垃圾回收算法：在年輕代用復(fù)制算法、在老年代用標(biāo)記清除、標(biāo)記整理算法，對于java不同的對象，生命周期不一樣，有的存活年齡短，有的存活年齡長，JVM是如何判斷java對象實(shí)例可以GC的呢？java一般引用的是根搜索算法，從GC ROOT節(jié)點(diǎn)開始搜索，如果對樣到GC ROOT對象節(jié)點(diǎn)沒有任何引用鏈相連，就認(rèn)為對象不可用；常常會(huì)有一些大對象初始化，年輕代放不了，會(huì)借代老年代存大對象，就容易產(chǎn)生Full GC的情況，所以對于大對象讀取一定不要一次性讀入內(nèi)存，而是按照行讀取處理；如果因?yàn)槎褏^(qū)設(shè)置參數(shù)不合理，可以通過Xmx來調(diào)整堆區(qū)大小

方法區(qū)
在類加載過程中，會(huì)對class文件進(jìn)行讀取，轉(zhuǎn)化成二進(jìn)制流信息，最后轉(zhuǎn)化成元數(shù)據(jù)信息進(jìn)行存儲(chǔ)，包括類的全限定名稱、版本、

方法、字段等信息，這些在編譯時(shí)就JVM就分配內(nèi)存，這塊區(qū)域就是方法區(qū)，對于一些常量池等等也在這里分配；在方法區(qū)也涉及到垃圾回收，比如類的卸載、無用的常量、無用的類都會(huì)回收；一般不斷創(chuàng)建動(dòng)態(tài)代理會(huì)導(dǎo)致方法區(qū)的oom；可以通過MaxPermSize來調(diào)節(jié)方法區(qū)的大小

虛擬機(jī)棧

這一塊區(qū)域?qū)儆诰€程私有的，線程要想在java虛擬機(jī)正常的運(yùn)行，不僅需要計(jì)數(shù)器來記錄行號，線程還需要擁有自己的運(yùn)行空間，虛擬機(jī)棧可以保存方法的運(yùn)行順序，方法局部變量以及方法在運(yùn)算時(shí)，需要自己的內(nèi)存空間；我們把這一塊區(qū)域稱為虛擬機(jī)棧；每一個(gè)棧內(nèi)部劃分局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈表、返回地址；方法執(zhí)行都需要一塊區(qū)域存儲(chǔ)局部變量，方法運(yùn)算時(shí)，需要內(nèi)存空間，就是操作數(shù)棧，有些方法需要運(yùn)行時(shí)加載指定的方法，符號引用轉(zhuǎn)化直接引用，就需要?jiǎng)討B(tài)鏈表；方法遇到返回指令或者拋出異常就會(huì)返回，需要返回地址；在這一塊，也會(huì)產(chǎn)生oom問題，典型的就是線程池沒有設(shè)置大小，代碼中不斷創(chuàng)建線程，而創(chuàng)建線程需要內(nèi)存空間，物理內(nèi)存不夠就會(huì)oom，遇到這樣問題通常是調(diào)小棧的大小，通過Xss來設(shè)置

本地方法棧

和虛擬機(jī)棧一樣，在java虛擬機(jī)中，不但要執(zhí)行java方法，還要執(zhí)行本地方法，也會(huì)產(chǎn)生oom，除此之外，也會(huì)和虛擬機(jī)棧一樣產(chǎn)生棧溢出異常

程序計(jì)數(shù)器*

眾所周知，虛擬機(jī)在處理多線程時(shí)，通過輪流切換線程，來獲取CPU資源的，為了保證每個(gè)線程下次能夠正確的執(zhí)行，需要記錄每個(gè)線程的當(dāng)前運(yùn)行位置；程序計(jì)數(shù)器的作用就是將各個(gè)線程下次所執(zhí)行的（字節(jié)碼）行號（準(zhǔn)確來說是指令的地址）記錄下來，以保證其下次執(zhí)行時(shí)可以正確的執(zhí)行；內(nèi)存很小，幾乎可以忽略不計(jì)

講述完這2個(gè)概念之后，我們來看看java的一些常見問題

NoSuchMethodException

出現(xiàn)這種問題的原因一般有2種可能：java ClassLoader機(jī)制、java二方包沖突；針對ClassLoader問題可以在JVM配置-XX:+TraceClassLoading 來跟蹤class加載過程，二方包沖突直接排除pom文件沖突文件即可

三、數(shù)據(jù)庫mysql慢sql優(yōu)化

想必大家在和數(shù)據(jù)庫打交道的時(shí)候，經(jīng)常會(huì)遇到sql查詢很慢，數(shù)據(jù)量大的時(shí)候，性能很低。碰到這樣的問題有一定開發(fā)經(jīng)驗(yàn)的同學(xué)想到通過explain執(zhí)行計(jì)劃，來分析sql；綜合業(yè)務(wù)場景建立合適的索引來優(yōu)化；在這里我只是總結(jié)一下如何分析慢sql，以及如何建立索引

談到索引，不得不提到數(shù)據(jù)結(jié)構(gòu)；mysql是一種關(guān)系型基于磁盤的關(guān)系型數(shù)據(jù)庫，對于磁盤的IO和從內(nèi)存讀取數(shù)據(jù)性能相差好幾個(gè)量級，所以為了減少磁盤的IO次數(shù)，使用了B+樹這種多路平衡樹來存儲(chǔ)數(shù)據(jù)，樹的高度越低，磁盤IO次數(shù)就會(huì)越少；假設(shè)數(shù)據(jù)量為N，每個(gè)磁盤塊數(shù)據(jù)量為m，則樹的高度h=log（m+1）*N，而m=磁盤塊的大小/數(shù)據(jù)項(xiàng)的大小 對于B+樹，所有數(shù)據(jù)都存在葉子節(jié)點(diǎn)，這樣就會(huì)內(nèi)節(jié)點(diǎn)磁盤塊就會(huì)存儲(chǔ)更多的內(nèi)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)的索引范圍更大，對于磁盤塊大小都固定1頁大大小，默認(rèn)為16K，這樣數(shù)據(jù)項(xiàng)的大小越大，m越小，高度就越低。

原理闡述清楚之后，了解一下建立索引的一些原則

最左匹配原則，因?yàn)榻⑺阉鳂涞臅r(shí)候，是通過從做往右的順序建立的，當(dāng)遇到范圍查詢、模糊查詢或者并集查詢，索引不會(huì)生效
索引字段區(qū)分度要高，也就是不重復(fù)比例要大，這樣建立索引區(qū)分?jǐn)?shù)據(jù)才明顯

索引字段不能參與計(jì)算，因?yàn)锽+樹存儲(chǔ)的data域都是字段名稱，如果含有函數(shù)計(jì)算，成本相當(dāng)大

sql語句通過執(zhí)行計(jì)劃分析，關(guān)鍵看rows大小，一般情況下rows越小，查詢越快，避免全表查詢，多表查詢盡量采用union或union all來查詢

關(guān)于mysql存儲(chǔ)引擎的區(qū)別：從5.7之后，myql默認(rèn)采用InnoDB存儲(chǔ)引擎，相比MyISAM存儲(chǔ)引擎，InnoDB支持事務(wù)特性，同樣使用B+樹，但葉子節(jié)點(diǎn)data域存儲(chǔ)值不一樣，InnoDB存儲(chǔ)的是完整的數(shù)據(jù)記錄，默認(rèn)按照主鍵索引順序，所以InnoDB一定要有主鍵，對于普通索引，data域存儲(chǔ)的是主鍵索引的值，所以需要先到普通索引樹中找到主鍵索引，再到主索引樹中找到相應(yīng)的記錄。而MyISAM葉子節(jié)點(diǎn)存儲(chǔ)的是數(shù)據(jù)的地址，數(shù)據(jù)文件和索引文件是分離的

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論