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

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

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

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

CPU瓶頸如何分析

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

確認目標進程

查看對應進程信息 -> 登錄容器查看容器id -> 進入容器 -> 容器內(nèi)top命令查看CPU過高的目標進程

#top
#ps -ef | grep 進程號
#sudo docker ps -a
#sudo docker exec -it 容器id bash
#top

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

#sar -u 1 3

打印堆棧信息

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

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

通過sftp命令將文件copy到本地機器上，來分析堆棧日志信息；如果裝了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 ~/

分析堆棧信息

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

#top -H p 進程id

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

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

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

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

#free -m

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

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

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

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

IO瓶頸如何分析

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

#iostat -d -k -x 1 1

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

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

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

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

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

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

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

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

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

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

那四次分手呢？

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

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

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

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

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

追蹤online應用java動態(tài)運行細節(jié)

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

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

二、項目代碼常見問題排查

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

類加載機制

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

類加載過程，類加載器采用的是雙親委派原則，首先是啟動類加載器BootStrap加載，然后是擴展類加載器、應用程序加載器、

自定義類加載器

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

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

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

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

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

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

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

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

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

堆區(qū)

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

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

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

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

虛擬機棧

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

本地方法棧

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

程序計數(shù)器*

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

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

NoSuchMethodException

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

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

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

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

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

最左匹配原則，因為建立搜索樹的時候，是通過從做往右的順序建立的，當遇到范圍查詢、模糊查詢或者并集查詢，索引不會生效
索引字段區(qū)分度要高，也就是不重復比例要大，這樣建立索引區(qū)分數(shù)據(jù)才明顯

索引字段不能參與計算，因為B+樹存儲的data域都是字段名稱，如果含有函數(shù)計算，成本相當大

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

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

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

最新評論