如果系統出現異常或者業務有異常,首先想到的都是查看業務日志
查看日志工具:
less 或者more
grep
tail -f filename 查看實時的最新內容
ps:切忌vim直接打開大日志文件,因為會直接加載到內存的
java應用很多瓶頸在數據庫,一條sql沒寫好導致慢查詢,可能就會帶來應用帶來致命危害。
如果出現Could not get JDBC Connection 、接口響應慢、線程打滿等,
需要登錄線上庫,
查看數據庫連接情況:show processlist,查看當前數據庫的連接情況,確實由於慢查詢造成,需要手動kill
java虛擬機相關的問題一般多是以下幾種問題:gc時間過長、OOM、死鎖、線程block、線程數暴漲等問題。一般通過以下幾個工具都能定位出問題。
jps命令
jinfo命令
jstat命令
jstack命令
jmap命令
發生OOM問題一般服務都會crash,業務日志會有OutOfMemoryError。OOM一般都是出現了內存洩露,需要查看OOM時候的jvm堆的快照,如果配置了-XX:+HeapDumpOnOutOfMemoryError, 在發生OOM的時候會在-XX:HeapDumpPath生成堆的dump文件,結合MAT,可以對dump文件進行分析,查找出發生OOM的原因. 關於MAT使用不詳述了,google上一堆(http://inter12.iteye.com/blog/1407492)。
ps.
1、服務器的內存一般較大,所以要保證服務器的磁盤空間大於內存大小
2、另外手動dump堆快照,可以使用命令jmap -dump:format=b,file=file_name pid 或者kill -3 pid
死鎖原因是兩個或者多個線程相互等待資源,現象一般是出現線程hung住,更嚴重會出現線程數暴漲,系統出現api alive報警等。查看死鎖最好的方法就是分析當時的線程棧。
具體case 可以參考jstack命令裡面的例子
用到的命令:
jps -v
jstack -l pid
jstack -l pid |wc -l
jstack -l pid |grep "BLOCKED"|wc -l
jstack -l pid |grep "Waiting on condition"|wc -l
線程block問題一般是等待io、等待網絡、等待監視器鎖等造成,可能會導致請求超時、造成造成線程數暴漲導致系統502等。
如果出現這種問題,主要是關注jstack 出來的BLOCKED、Waiting on condition、Waiting on monitor entry等狀態信息。
如果大量線程在“waiting for monitor entry”:
可能是一個全局鎖阻塞住了大量線程。
如果短時間內打印的 thread dump 文件反映,隨著時間流逝,waiting for monitor entry 的線程越來越多,沒有減少的趨勢,可能意味著某些線程在臨界區裡呆的時間太長了,以至於越來越多新線程遲遲無法進入臨界區。
todo
先貼一個文章占坑:http://www.oracle.com/technetwork/cn/articles/java/g1gc-1984535-zhs.html
top命令(參考https://linux.cn/article-2352-1.html)
主要關注cpu的load,以及比較耗cpu的進程
由於現在服務器都是虛擬機,還要關注st(st 的全稱是 Steal Time ,是分配給運行在其它虛擬機上的任務的實際 CPU 時間)
常用交互命令:
h 幫助,十分有用
R: 反向排序
x:將排序字段高亮顯示(縱列)
y 將運行進程高亮顯示(橫行)
shift+> 或shift+<:切換排序字段
d或s: 設置顯示的刷新間隔
f: 字段管理 設置顯示的字段
k:kill進程
free命令:
free -m -c10 -s1
-m:以MB為單位顯示,其他的有-k -g -b
-s: 間隔多少秒持續觀察內存使用狀況
-c:觀察多少次
vmstat命令:(http://man.linuxde.net/vmstat)
vmstat 1 10
1表示每隔1s輸出一次,10 表示輸出10次
兩個參數需要關注
r: 運行隊列中進程數量,這個值也可以判斷是否需要增加CPU。(長期大於1)
b: 等待IO的進程數量。
iostat 命令(http://www.orczhou.com/index.php/2010/03/iostat-detail/)
iostat -m 1 10