導讀：有哪些常見的線上故障？如何快速定位問題？本文詳細總結工作中的經(jīng)驗，從服務器、Java應用、數(shù)據(jù)庫、Redis、網(wǎng)絡和業(yè)務六個層面分享線上故障排查的思路和技巧。較長，同學們可收藏后再看。
前言
線上定位問題時，主要靠監(jiān)控和日志。一旦超出監(jiān)控的范圍，則排查思路很重要，按照流程化的思路來定位問題，能夠讓我們在定位問題時從容、淡定，快速的定位到線上的問題。
線上問題定位思維導圖
一? 服務器層面
1.1? 磁盤
1.1.1? 問題現(xiàn)象
當磁盤容量不足的時候，應用時常會拋出如下的異常信息：
java.io.IOException: 磁盤空間不足
或是類似如下告警信息：
1.1.2? 排查思路
1.1.2.1? 利用 df 查詢磁盤狀態(tài)
利用以下指令獲取磁盤狀態(tài)：
df -h
結果是：
可知?/?路徑下占用量最大。
1.1.2.2? 利用 du 查看文件夾大小
利用以下指令獲取目錄下文件夾大?。?/p>
du -sh *
結果是：
可知root文件夾占用空間最大，然后層層遞推找到對應的最大的一個或數(shù)個文件夾。
1.1.2.3? 利用 ls 查看文件大小
利用以下指令獲取目錄下文件夾大小：
ls -lh
結果是：
可以找到最大的文件是日志文件，然后使用rm指令進行移除以釋放磁盤。
1.1.3? 相關命令
1.1.3.1? df
主要是用于顯示目前在 Linux 系統(tǒng)上的文件系統(tǒng)磁盤使用情況統(tǒng)計。
（1）常用參數(shù)
啟動參數(shù)：
（2）結果參數(shù)
1.1.3.2? du
主要是為了顯示目錄或文件的大小。
（1）常用參數(shù)
啟動參數(shù)：
（2）結果參數(shù)
1.1.3.3? ls
主要是用于顯示指定工作目錄下的內容的信息。
（1）常用參數(shù)
啟動參數(shù)：
（2）結果參數(shù)
1.2? CPU過高
1.2.1? 問題現(xiàn)象
當CPU過高的時候，接口性能會快速下降，同時監(jiān)控也會開始報警。
1.2.2? 排查思路
1.2.2.1? 利用 top 查詢CPU使用率最高的進程
利用以下指令獲取系統(tǒng)CPU使用率信息：
top
結果是：
從而可以得知pid為14201的進程使用CPU最高。
1.2.3? 相關命令
1.2.3.1? top
（1）常用參數(shù)
啟動參數(shù)：
top進程內指令參數(shù)：
（2）結果參數(shù)
二? 應用層面
2.1? Tomcat假死案例分析
2.1.1? 發(fā)現(xiàn)問題
監(jiān)控平臺發(fā)現(xiàn)某個Tomcat節(jié)點已經(jīng)無法采集到數(shù)據(jù)，連上服務器查看服務器進程還在，netstat -anop|grep 8001端口也有監(jiān)聽，查看日志打印時斷時續(xù)。
2.2.2? 查詢日志
查看NG日志，發(fā)現(xiàn)有數(shù)據(jù)進入到當前服務器（有8001和8002兩個Tomcat），NG顯示8002節(jié)點訪問正常，8001節(jié)點有404錯誤打印，說明Tomcat已經(jīng)處于假死狀態(tài)，這個Tomcat已經(jīng)不能正常工作了。
過濾Tomcat節(jié)點的日志，發(fā)現(xiàn)有OOM的異常,但是重啟后，有時候Tomcat掛掉后，又不會打印如下OOM的異常：
TopicNewController.getTopicSoftList() error="Java heap space From class java.lang.OutOfMemoryError"appstore_apitomcat
2.2.3? 獲取內存快照
在一次OOM發(fā)生后立刻抓取內存快照,需要執(zhí)行命令的用戶與JAVA進程啟動用戶是同一個，否則會有異常：
/data/program/jdk/bin/jmap -dump:live,format=b,file=/home/www/jmaplogs/jmap-8001-2.bin18760ps -ef|grepstore.cn.xml|grep-vgrep|awk'{print $2}'|xargs /data/program/jdk-1.8.0_11/bin/jmap -dump:live,format=b,file=api.bin
內存dump文件比較大，有1.4G，先壓縮，然后拉取到本地用7ZIP解壓。
linux壓縮dump為.tgz。
在windows下用7zip需要經(jīng)過2步解壓：
.bin.tgz---.bin.tar--.bin
2.2.4? 分析內存快照文件
使用Memory Analyzer解析dump文件，發(fā)現(xiàn)有很明顯的內存泄漏提示。
點擊查看詳情，發(fā)現(xiàn)定位到了代碼的具體某行，一目了然：
查看shallow heap與retained heap能發(fā)現(xiàn)生成了大量的Object(810325個對象)，后面分析代碼發(fā)現(xiàn)是上報softItem對象超過300多萬個對象，在循環(huán)的時候，所有的數(shù)據(jù)全部保存在某個方法中無法釋放，導致內存堆積到1.5G，從而超過了JVM分配的最大數(shù)，從而出現(xiàn)OOM。
java.lang.Object[810325] @ 0xb0e971e0
2.2.5? 相關知識
2.2.5.1? JVM內存
2.2.5.2? 內存分配的流程
如果通過逃逸分析，則會先在TLAB分配，如果不滿足條件才在Eden上分配。
2.2.4.3? GC
（1）GC觸發(fā)的場景
（2）GC Roots
GC Roots有4種對象：
虛擬機棧(棧楨中的本地變量表)中的引用的對象，就是平時所指的java對象，存放在堆中。
方法區(qū)中的類靜態(tài)屬性引用的對象，一般指被static修飾引用的對象，加載類的時候就加載到內存中。
方法區(qū)中的常量引用的對象。
本地方法棧中JNI（native方法)引用的對象。
（3）GC算法?
串行只使用單條GC線程進行處理，而并行則使用多條。
多核情況下，并行一般更有執(zhí)行效率，但是單核情況下，并行未必比串行更有效率。
STW會暫停所有應用線程的執(zhí)行，等待GC線程完成后再繼續(xù)執(zhí)行應用線程，從而會導致短時間內應用無響應。
Concurrent會導致GC線程和應用線程并發(fā)執(zhí)行，因此應用線程和GC線程互相搶用CPU，從而會導致出現(xiàn)浮動垃圾，同時GC時間不可控。
（4）新生代使用的GC算法
新生代算法都是基于Coping的，速度快。
Parallel Scavenge：吞吐量優(yōu)先。
吞吐量=運行用戶代碼時間 /（運行用戶代碼時間 + 垃圾收集時間）
（5）老年代使用的GC算法
Parallel Compacting
Concurrent Mark-Sweep(CMS)
（6）垃圾收集器總結
（7）實際場景中算法使用的組合
（8）GC日志格式
（a）監(jiān)控內存的OOM場景
不要在線上使用jmap手動抓取內存快照，其一系統(tǒng)OOM時手工觸發(fā)已經(jīng)來不及，另外在生成dump文件時會占用系統(tǒng)內存資源，導致系統(tǒng)崩潰。只需要在JVM啟動參數(shù)中提取設置如下參數(shù)，一旦OOM觸發(fā)會自動生成對應的文件，用MAT分析即可。
# 內存OOM時，自動生成dump文件 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/logs/
如果Young GC比較頻繁，5S內有打印一條，或者有Old GC的打印，代表內存設置過小或者有內存泄漏，此時需要抓取內存快照進行分享。
（b）Young Gc日志
2020-09-23T01:45:05.487+0800: 126221.918: [GC (Allocation Failure) 2020-09-23T01:45:05.487+0800: 126221.918: [ParNew: 1750755K->2896K(1922432K), 0.0409026 secs] 1867906K->120367K(4019584K), 0.0412358 secs] [Times: user=0.13 sys=0.01, real=0.04 secs]
（c）Old GC日志
2020-10-27T20:27:57.733+0800: 639877.297: [Full GC (Heap Inspection Initiated GC) 2020-10-27T20:27:57.733+0800: 639877.297: [CMS: 165992K->120406K(524288K), 0.7776748 secs] 329034K->120406K(1004928K), [Metaspace: 178787K->178787K(1216512K)], 0.7787158 secs] [Times: user=0.71 sys=0.00, real=0.78 secs]
2.2? 應用CPU過高
2.2.1? 發(fā)現(xiàn)問題
一般情況下會有監(jiān)控告警進行提示：
以上文章來源于阿里技術?，作者小峯
阿里技術
阿里巴巴官方技術號，關于阿里的技術創(chuàng)新均呈現(xiàn)于此。
