內存泄漏排查攻略之:Show me your Memory

  java 語言有個神奇的地方,那就是你時不時會去關注下內存。(當然了,任何牛逼的同學都應該關注內存)

  今天我們就來這么個問題現場吧:某應用運行了一段時間后,ecs監控報警了,內存比較高了,怎么辦?隨著時間的推移,發現內存越來越高緩緩增長,怎么辦?

  凡事講究證據,報警系統說內存緊張就緊張嗎,還得自己去驗一下。

如何確認內存問題?這太重要了! 其實只要給我看你內存里所有東西(Show me your Memory),我豈有找不到問題根源的道理?以下是幾種查看內存問題的方法供諸君參考:

1. top 等查看系統內存概況

  top:顯示所有進程運行情況,按M鍵按照內存大小排序,立馬看到罪魁禍首。具體命令請參考網上資料。

  top簡要使用方法如下:

使用格式:
top [-] [d] [p] [q] [c] [C] [S] [s] [n]
參數說明:
d:指定每兩次屏幕信息刷新之間的時間間隔。當然用戶可以使用s交互命令來改變之。
p:通過指定監控進程ID來僅僅監控某個進程的狀態。
q:該選項將使top沒有任何延遲的進行刷新。如果調用程序有超級用戶權限,那么top將以盡可能高的優先級運行。
S:指定累計模式。
s:使top命令在安全模式中運行。這將去除交互命令所帶來的潛在危險。
i:使top不顯示任何閑置或者僵死進程。
c:顯示整個命令行而不只是顯示命令名。

常用命令說明:
Ctrl+L:擦除并且重寫屏幕
K:終止一個進程。系統將提示用戶輸入需要終止的進程PID,以及需要發送給該進程什么樣的信號。一般的終止進程可以使用15信號;如果不能正常結束那就使用信號9強制結束該進程。默認值是信號15。在安全模式中此命令被屏蔽。
i:忽略閑置和僵死進程。這是一個開關式命令。
q:退出程序
r:重新安排一個進程的優先級別。系統提示用戶輸入需要改變的進程PID以及需要設置的進程優先級值。輸入一個正值將使優先級降低,反之則可以使該進程擁有更高的優先權。默認值是10。
S:切換到累計模式。
s:改變兩次刷新之間的延遲時間。系統將提示用戶輸入新的時間,單位為s。如果有小數,就換算成m s。輸入0值則系統將不斷刷新,默認值是5 s。需要注意的是如果設置太小的時間,很可能會引起不斷刷新,從而根本來不及看清顯示的情況,而且系統負載也會大大增加。
f或者F:從當前顯示中添加或者刪除項目。
o或者O:改變顯示項目的順序
l:切換顯示平均負載和啟動時間信息。
m:切換顯示內存信息。
t:切換顯示進程和CPU狀態信息。
c:切換顯示命令名稱和完整命令行。
M:根據駐留內存大小進行排序。
P:根據CPU使用百分比大小進行排序。
T:根據時間/累計時間進行排序。
W:將當前設置寫入~/.toprc文件中。

  另外在內存查看方面,還可以使用 free用于快速直接查看內存,還可以看到有多少是系統緩存;(系統緩存一般不被計入真正已使用內存中)

 

2. jmx 快速發現jvm中的內存異常項

  jmx,如果開啟了jmx,則我們可以直接通過jvisualvm查看內存,線程監控情況,還可以查看其他jmx指標;
  從這里你可以,看到內存的變化趨勢,垃圾回收,cpu變化趨勢等等,很多直觀的問題完全可以在這一環節發現。
  另外,你可以通過采集cpu和采集內存的方式,發現代碼中的瓶頸點。
  可以說,jmx是我們進行代碼優化或者參數調優的絕對王者工具。

  性能問題,可以適當進行CPU/內存采樣,以快速發現瓶頸點!

  建議新增插件: 

    Btrace Workbench  用于遠程調試,也許有用;

    BufferMonitor 用于查看堆外內存情況,其實可能不準;

    Threads Inspector 用于快速查看各線程情況;

    VisualJVM-MBeans 用于查看 jmx 暴露出來的 指標信息,可作為業務監控使用;

 

 

3. jmap dump 詳細分析jvm的內存使用情況

  jmap dump,發現內存異常,而其他方面沒啥思路時,那就jvm內存dump下來,慢慢分析。
  dump整個內存下來,全量分析,jmap -dump:format=b,file=/tmp/a.dump . 然后就可以使用jvm內存分析工具進行分析了,如 mat 。分析工具的技巧可能還是需要去掌握下的,不過我這里簡單提兩個點,一個是看得到的堆內存,一個是不可達的堆內存,分析時就注意這兩點。一般可達堆內存是很好分析的,不可達堆內存則要憑借一定的經驗才能發現問題了。

  對于快速查詢,則直接在服務器上使用 jmap -heap 就可以查看了。

jmap -dump:format=b,file=/tmp/a.dump <pid> # dump倒是堆內存
jmap -heap <pid> # 直接在服務器上查看堆的使用情況

       會一些OQL查詢語言,將會對你的排查如虎添翼! 

 

4. lsof 列舉出正在使用的文件,看看是否能發現一些端倪

  lsof,這個工具用于排查是否存在很在很多超出預料的文件的情況,比如打開某文件未關閉,建立很多的socket連接等等。當然,發現問題只能靠眼力勁了。

lsof -p <pid> #查看進程打開的文件情況。

  lsof 使用詳細介紹參考網上資料: //www.eoxav.com/sparkbj/p/7161669.html

 

5. pmap 查看進程內存概要

  pmap,用于查看進程的內存映像信息, 發現內存中大塊的占用所在,以及分析內存可能存在的異常。

  從中,你可以看到哪些內存上面占用了多少內存,正常的內存如 JVM 所在內存段,應該是和你的堆內存一致的,而其他內存段,則是你看不到的地方,這些地方將是你排查內存泄漏的方向。

簡要命令下:
    pmap [ -x | -d ] [ -q ] pids...
結果樣例如下:
[[email protected] ~]# pmap -x 27466 
27466:   /usr/local/jdk1.8.0_211/bin/java -Dzookeeper.log.dir=. -Dzookeeper.root.logger=INFO,CONSOLE -cp /opt/zookeeper/zookeeper-3.4.14/bin/../zookeeper-server/target/classes:/opt/zookeeper/zookeeper-3.4.14/bin/../build/classes:/opt/zookeeper/zookeeper-3.4.14/bin/../zookeeper-server/target/lib/*.jar:/opt/zookeeper/zookeeper-3.4.14/bin/../build/lib/*.jar:/opt/zookeeper/zookeeper-3.4.14/bin/../lib/slf4j-log4j12-1.7.25.jar:/opt/zookeeper/zookeeper-3.4.14/bin/../lib/slf4j-api-1.7.25.jar:/opt/zookeeper/zookeeper-3.4.1
Address           Kbytes     RSS   Dirty Mode  Mapping
0000000000400000       4       4       0 r-x-- java
0000000000600000       4       4       4 r---- java
0000000000601000       4       4       4 rw--- java
...
00007fff10253000     136      36      36 rw---   [ stack ]
00007fff102ce000       8       4       0 r-x--   [ anon ]
ffffffffff600000       4       0       0 r-x--   [ anon ]
---------------- ------- ------- -------
total kB         5421732  100608   87672

  命令操作詳情請參考網上資料:: //www.eoxav.com/txw1958/archive/2012/07/26/linux-pmap.html

 

6. NMT,  nativeMemoryTracking jvm 的內存追蹤工具

  nmt,這個jdk8以后,jvm提供的內存跟蹤工具,nativeMemoryTracking, 可以用于排查內存方案的問題。 

-XX:NativeMemoryTracking=summary     # 開啟NMT追蹤
jcmd 1 VM.native_memory summary        # 查看當前的內存概況
jcmd 1 VM.native_memory baseline    # 創建基準 baseline
jcmd 1 VM.native_memory summary.diff    # 一段時間后,比對內存差異,可以用于發現內存的走向問題,如下
[[email protected] ~]# jcmd 5545 VM.native_memory summary.diff
5545:

Native Memory Tracking:

Total: reserved=5942859KB +2339KB, committed=4104347KB +1519KB

-                 Java Heap (reserved=4194304KB, committed=3645440KB)
                            (mmap: reserved=4194304KB, committed=3645440KB)

-                     Class (reserved=1109328KB +2056KB, committed=66640KB +264KB)
                            (classes #11172 +2)
                            (malloc=1360KB +8KB #15153 +331)
                            (mmap: reserved=1107968KB +2048KB, committed=65280KB +256KB)

-                    Thread (reserved=133119KB, committed=133119KB)
                            (thread #130)
                            (stack: reserved=132544KB, committed=132544KB)
                            (malloc=422KB #652)
                            (arena=152KB #256)

-                      Code (reserved=255919KB +247KB, committed=37519KB +1219KB)
                            (malloc=6319KB +247KB #8248 +270)
                            (mmap: reserved=249600KB, committed=31200KB +972KB)

-                        GC (reserved=209075KB +8KB, committed=188707KB +8KB)
                            (malloc=20659KB +8KB #28406 +320)
                            (mmap: reserved=188416KB, committed=168048KB)

-                  Compiler (reserved=277KB +5KB, committed=277KB +5KB)
                            (malloc=146KB +5KB #592 +9)
                            (arena=131KB #6)

-                  Internal (reserved=12648KB, committed=12648KB)
                            (malloc=12616KB #39090 +5)
                            (mmap: reserved=32KB, committed=32KB)

-                    Symbol (reserved=16444KB +8KB, committed=16444KB +8KB)
                            (malloc=12569KB +8KB #121265 +2)
                            (arena=3876KB #1)

-    Native Memory Tracking (reserved=3362KB +15KB, committed=3362KB +15KB)
                            (malloc=18KB #204 +2)
                            (tracking overhead=3344KB +15KB)

-               Arena Chunk (reserved=192KB, committed=192KB)
                            (malloc=192KB)

-                   Unknown (reserved=8192KB, committed=0KB)
                            (mmap: reserved=8192KB, committed=0KB)

  如上結果,我們可以得得出些結論,隨著時間的推移, code 部分的占用空間增加了最多(JIT), Compiler 也增加一些,而堆內存則一直保持不變!

 

7. perf,這是一個性能監控調優工具,但是我們也可能從中發現內存問題點

  可以先捕獲數據,然后進行性能分析,然后得到可疑的點。

幫助信息如下:

usage: perf [--version] [--help] [OPTIONS] COMMAND [ARGS]
 The most commonly used perf commands are:
   annotate        Read perf.data (created by perf record) and display annotated code
   archive         Create archive with object files with build-ids found in perf.data file
   bench           General framework for benchmark suites
   buildid-cache   Manage build-id cache.
   buildid-list    List the buildids in a perf.data file
   c2c             Shared Data C2C/HITM Analyzer.
   config          Get and set variables in a configuration file.
   data            Data file related processing
   diff            Read perf.data files and display the differential profile
   evlist          List the event names in a perf.data file
   ftrace          simple wrapper for kernel's ftrace functionality
   inject          Filter to augment the events stream with additional information
   kallsyms        Searches running kernel for symbols
   kmem            Tool to trace/measure kernel memory properties
   kvm             Tool to trace/measure kvm guest os
   list            List all symbolic event types
   lock            Analyze lock events
   mem             Profile memory accesses
   record          Run a command and record its profile into perf.data
   report          Read perf.data (created by perf record) and display the profile
   sched           Tool to trace/measure scheduler properties (latencies)
   script          Read perf.data (created by perf record) and display trace output
   stat            Run a command and gather performance counter statistics
   test            Runs sanity tests.
   timechart       Tool to visualize total system behavior during a workload
   top             System profiling tool.
   probe           Define new dynamic tracepoints
   trace           strace inspired tool

 See 'perf help COMMAND' for more information on a specific command.

  簡單示例:

    perf record -g -e cpu-clock -p 5545        # 記錄進程 5545 的相關性能信息
    perf report -i perf.data                # 讀取剛剛記錄的數據,可以顯示出種操作的占用情況,如下
Samples: 908  of event 'cpu-clock', Event count (approx.): 227000000
  Children      Self  Command  Shared Object       Symbol
+   32.27%     0.00%  java     libpthread-2.17.so  [.] start_thread
+   32.27%     0.00%  java     libjvm.so           [.] java_start
+   26.54%     0.00%  java     libjvm.so           [.] ConcurrentG1RefineThread::run
+   26.54%     0.11%  java     libjvm.so           [.] ConcurrentG1RefineThread::run_young_rs_sampling
+   25.77%     5.62%  java     libjvm.so           [.] YoungList::rs_length_sampling_next
+   22.58%     0.55%  java     [kernel.kallsyms]   [k] tracesys
+   11.01%     0.00%  java     perf-5545.map       [.] 0x00007f553ec1e981
+   10.79%     0.44%  java     libjvm.so           [.] JVM_Sleep
+    9.36%     0.55%  java     libjvm.so           [.] G1CollectorPolicy::update_incremental_cset_info
+    8.70%     0.55%  java     libjvm.so           [.] os::sleep
+    8.26%     0.00%  java     [unknown]           [k] 0xee83b0ac00709650
+    8.15%     0.99%  java     libpthread-2.17.so  [.] [email protected]@GLIBC_2.3.2
+    7.93%     0.00%  java     perf-5545.map       [.] 0x00007f553f7f7d30

 

  如果運氣碰巧的話,你有可能能查到某些異常的操作,從而推斷出問題所在。

 

8. gdb 調試工具dump出可疑內存

  gdb, linux下強大的調試工具,但是我們不用它來調試,我們只用來輸出內存的內容。即dump內存,前面用到的jmap dump只能看到jvm的內存信息,而gdb則可以看所有的,當然我們會用來看其他部分的內存。

    gdb attach <pid>                    # 先連接到進程中
    gdb dump memory /path/dump.bin 0x0011  0x0021    # dump 出內存段的信息,具體要 dump 的內存段地址,可以借助之前pmap 排查的結果,以及 cat /proc/<pid>/maps 中指示的地址段得出
    strings /path/dump.bin | less # 查看內存內容, 相信你能從中發現一些不一樣的東西

  

  以上,足夠你排查出你懷疑的內存泄露問題了。如果不能,說明你還用好工具,多練練!

       

嘮叨: 有心者,共勉之!

 

posted @ 2019-08-11 14:02 等你歸去來 閱讀(...) 評論(...) 編輯 收藏