2. 程式人生 > >Java堆外記憶體排查小結

Java堆外記憶體排查小結

阿新 • • 發佈：2018-12-31

timg.jpeg

簡介

JVM堆外記憶體難排查但經常會出現問題，這可能是目前最全的JVM堆外記憶體排查思路。

通過本文，你應該瞭解：

  • pmap 命令
  • gdb 命令
  • perf 命令
  • 記憶體 RSS、VSZ的區別
  • java NMT

起因

這幾天遇到一個比較奇怪的問題，覺得有必要和大家分享一下。我們的一個服務，執行在docker上，在某個版本之後，佔用的記憶體開始增長，直到docker分配的記憶體上限，但是並不會OOM。版本的更改如下：

  • 升級了基礎軟體的版本
  • 將docker的記憶體上限由4GB擴充套件到8GB
  • 上上個版本的一項變動是使用了EhCache的Heap快取
  • 沒有讀檔案，也沒有mmap操作

使用jps 檢視啟動引數，發現分配了大約3GB的堆記憶體

[root]$ jps -v
75 Bootstrap -Xmx3000m -Xms3000m  -verbose:gc -Xloggc:/home/logs/gc.log -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSCompactAtFullCollection -XX:MaxTenuringThreshold=10 -XX:MaxPermSize=128M -XX:SurvivorRatio=3 -XX:NewRatio=2 -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+UseParNewGC -XX:+UseConcMarkSweepGC

使用ps檢視程序使用的記憶體和虛擬記憶體 ( Linux記憶體管理 )。除了虛擬記憶體比較高達到17GB以外，實際使用的記憶體RSS也誇張的達到了7GB，遠遠超過了-Xmx的設定。

[root]$ ps -p 75 -o rss,vsz  

RSS    VSZ 7152568 17485844

排查過程

明顯的，是有堆外記憶體的使用，不太可能是由於EhCache引起的（因為我們使用了heap方式）。瞭解到基礎軟體的升級涉及到netty版本升級，netty會用到一些DirectByteBuffer，第一輪排查我們採用如下方式：

  • jmap -dump:format=b,file=75.dump 75 通過分析堆記憶體找到DirectByteBuffer的引用和大小
  • 部署一個升級基礎軟體之前的版本，持續觀察
  • 部署另一個版本，更改EhCache限制其大小到1024M
  • 考慮到可能由Docker的記憶體分配機制引起，部署一例項到實體機

結果4個環境中的服務，無一例外的都出現了記憶體超用的問題。問題很奇怪，寶寶睡不著覺。

pmap

為了進一步分析問題，我們使用pmap檢視程序的記憶體分配，通過RSS升序序排列。結果發現除了地址000000073c800000上分配的3GB堆以外，還有數量非常多的64M一塊的記憶體段，還有巨量小的實體記憶體塊對映到不同的虛擬記憶體段上。但到現在為止，我們不知道里面的內容是什麼，是通過什麼產生的。

[root]$ pmap -x 75  | sort -n -k3

.....省略N行

0000000040626000   55488   55484   55484 rwx--    [ anon ]

00007fa07c000000   65536   55820   55820 rwx--    [ anon ]

00007fa044000000   65536   55896   55896 rwx--    [ anon ]

00007fa0c0000000   65536   56304   56304 rwx--    [ anon ]

00007f9db8000000   65536   56360   56360 rwx--    [ anon ]

00007fa0b8000000   65536   56836   56836 rwx--    [ anon ]

00007fa084000000   65536   57916   57916 rwx--    [ anon ]

00007f9ec4000000   65532   59752   59752 rwx--    [ anon ]

00007fa008000000   65536   60012   60012 rwx--    [ anon ]

00007f9e58000000   65536   61608   61608 rwx--    [ anon ]

00007f9f18000000   65532   61732   61732 rwx--    [ anon ]

00007fa018000000   65532   61928   61928 rwx--    [ anon ]

00007fa088000000   65536   62336   62336 rwx--    [ anon ]

00007fa020000000   65536   62428   62428 rwx--    [ anon ]

00007f9e44000000   65536   64352   64352 rwx--    [ anon ]

00007f9ec0000000   65528   64928   64928 rwx--    [ anon ]

00007fa050000000   65532   65424   65424 rwx--    [ anon ]

00007f9e08000000   65512   65472   65472 rwx--    [ anon ]

00007f9de0000000   65524   65512   65512 rwx--    [ anon ]

00007f9dec000000   65532   65532   65532 rwx--    [ anon ]

00007f9dac000000   65536   65536   65536 rwx--    [ anon ]

00007f9dc8000000   65536   65536   65536 rwx--    [ anon ]

00007f9e30000000   65536   65536   65536 rwx--    [ anon ]

00007f9eb4000000   65536   65536   65536 rwx--    [ anon ]

00007fa030000000   65536   65536   65536 rwx--    [ anon ]

00007fa0b0000000   65536   65536   65536 rwx--    [ anon ]

000000073c800000 3119140 2488596 2487228 rwx--    [ anon ]

total kB        17629516 7384476 7377520

通過google，找到以下資料 Linux glibc >= 2.10 (RHEL 6) malloc may show excessive virtual memory usage)

文章指出造成應用程式大量申請64M大記憶體塊的原因是由Glibc的一個版本升級引起的，通過export MALLOC_ARENA_MAX=4可以解決VSZ佔用過高的問題。雖然這也是一個問題，但卻不是我們想要的，因為我們增長的是實體記憶體，而不是虛擬記憶體。

NMT

幸運的是 JDK1.8有Native Memory Tracker可以幫助定位。通過在啟動引數上加入-XX:NativeMemoryTracking=detail就可以啟用。在命令列執行jcmd可檢視記憶體分配。

#jcmd 75 VM.native_memory summary

Native Memory Tracking: Total: reserved=5074027KB, committed=3798707KB -                 Java Heap (reserved=3072000KB, committed=3072000KB)                            (mmap: reserved=3072000KB, committed=3072000KB) -                     Class (reserved=1075949KB, committed=28973KB)                            (classes #4819)                            (malloc=749KB #13158)                            (mmap: reserved=1075200KB, committed=28224KB) -                    Thread (reserved=484222KB, committed=484222KB)                            (thread #470)                            (stack: reserved=482132KB, committed=482132KB)                            (malloc=1541KB #2371)                            (arena=550KB #938) -                      Code (reserved=253414KB, committed=25070KB)                            (malloc=3814KB #5593)                            (mmap: reserved=249600KB, committed=21256KB) -                        GC (reserved=64102KB, committed=64102KB)                            (malloc=54094KB #255)                            (mmap: reserved=10008KB, committed=10008KB) -                  Compiler (reserved=542KB, committed=542KB)                            (malloc=411KB #543)                            (arena=131KB #3) -                  Internal (reserved=50582KB, committed=50582KB)                            (malloc=50550KB #13713)                            (mmap: reserved=32KB, committed=32KB) -                    Symbol (reserved=6384KB, committed=6384KB)                            (malloc=4266KB #31727)                            (arena=2118KB #1) -    Native Memory Tracking (reserved=1325KB, committed=1325KB)                            (malloc=208KB #3083)                            (tracking overhead=1117KB) -               Arena Chunk (reserved=231KB, committed=231KB)                            (malloc=231KB) -                   Unknown (reserved=65276KB, committed=65276KB)                            (mmap: reserved=65276KB, committed=65276KB)

雖然pmap得到的記憶體地址和NMT大體能對的上，但仍然有不少記憶體去向成謎。雖然是個好工具但問題並不能解決。

gdb

非常好奇64M或者其他小記憶體塊中是什麼內容，接下來通過gdbdump出來。讀取/proc目錄下的maps檔案，能精準的知曉目前程序的記憶體分佈。

以下指令碼通過傳入程序id，能夠將所關聯的記憶體全部dump到檔案中（會影響服務，慎用）。

grep rw-p /proc/$1/maps | sed -n 's/^\([0-9a-f]*\)-\([0-9a-f]*\) .*$/\1 \2/p' | while read start stop; do gdb --batch --pid $1 -ex "dump memory $1-$start-$stop.dump 0x$start 0x$stop"; done

更多時候，推薦之dump一部分記憶體。(再次提醒操作會影響服務，注意dump的記憶體塊大小，慎用)。

gdb --batch --pid 75 -ex "dump memory a.dump 0x7f2bceda1000 0x7f2bcef2b000
[root]$ du -h *
dump 4.0K
55-00600000-00601000.dump 400K
55-00eb7000-00f1b000.dump 0
55-704800000-7c0352000.dump 47M
55-7f2840000000-7f2842eb8000.dump 53M
55-7f2848000000-7f284b467000.dump 64M
55-7f284c000000-7f284fffa000.dump 64M
55-7f2854000000-7f2857fff000.dump 64M
55-7f285c000000-7f2860000000.dump 64M
55-7f2864000000-7f2867ffd000.dump 1016K
55-7f286a024000-7f286a122000.dump 1016K
55-7f286a62a000-7f286a728000.dump 1016K
55-7f286d559000-7f286d657000.dump

是時候檢視裡面的內容了

[root]$ view 55-7f284c000000-7f284fffa000.dump
^@^@X+^?^@^@^@^@^@d(^?^@^@^@ ÿ^C^@^@^@^@^@ ÿ^C^@^@^@^@^@^@^@^@^@^@^@^@±<97>p^C^@^@^@^@ 8^^Z+^?^@^@ ^@^@d(^?^@^@ 8^^Z+^?^@^@ ^@^@d(^?^@^@
achine":524993642,"timeSecond":1460272569,"inc":2145712868,"new":false},"device":{"client":"android","uid":"xxxxx","version":881},"
device_android":{"BootSerialno":"xxxxx","CpuInfo":"0-7","MacInfo":"2c:5b:b8:b0:d5:10","RAMSize":"4027212","SdcardInfo":"xxxx","Serialno":"xxxx",
"android_id":"488aedba19097476","buildnumber":"KTU84P/1416486236","device_ip":"0.0.0.0","mac":"2c:5b:b8:b0:d5:10","market_source":"12","model":"OPPO ...more

納尼？這些內容不應該在堆裡面麼？為何還會使用額外的記憶體進行分配？上面已經排查netty申請directbuffer的原因了，那麼還有什麼地方在分配堆外記憶體呢？

perf

傳統工具失靈，快到了黔驢技窮的時候了，是時候祭出神器perf了。

使用 perf record -g -p 55 開啟監控棧函式呼叫。執行一段時間後Ctrl+C結束，會生成一個檔案perf.data。

執行perf report -i perf.data檢視報告。
1.jpeg

如圖，程序大量執行bzip相關函式。搜尋zip，結果如下：

2.jpeg

-.-!

程序呼叫了Java_java_util_zip_Inflater_inflatBytes() 申請了記憶體，僅有一小部分呼叫Deflater釋放記憶體。與pmap記憶體地址相比對，確實是bzip在搞鬼。

解決

java專案搜尋zip定位到程式碼，發現確實有相關bzip壓縮解壓操作，而且GZIPInputStream有個地方沒有close。

GZIPInputStream使用Inflater申請堆外記憶體，Deflater釋放記憶體，呼叫close()方法來主動釋放。如果忘記關閉，Inflater物件的生命會延續到下一次GC。在此過程中，堆外記憶體會一直增長。

原始碼：

public byte[] decompress ( byte[] input) throws IOException {
                ByteArrayOutputStream out = new ByteArrayOutputStream();
                IOUtils.copy(new GZIPInputStream(new ByteArrayInputStream(input)), out);
                return out.toByteArray();
            }

修改後：

 public byte[] decompress(byte[] input) throws IOException {
        ByteArrayOutputStream out = new ByteArrayOutputStream();
        GZIPInputStream gzip = new GZIPInputStream(new ByteArrayInputStream(input));
        IOUtils.copy(gzip, out);
        gzip.close();
        return out.toByteArray();
    }

經觀察，問題解決。


訂閱微信公眾號，小姐姐，教你玩架構～

相關推薦

Java堆外記憶體排查小結

簡介JVM堆外記憶體難排查但經常會出現問題，這可能是目前最全的JVM堆外記憶體排查思路。通過本文，你應該瞭解：pmap 命令gdb 命令perf 命令記憶體 RSS、VSZ的區別java NMT起因這幾天遇到一個比較奇怪的問題，覺得有必要和大家分享一下。我們的一個服務，執行在

超乾貨！Cassandra Java堆外記憶體排查經歷全記錄

背景 最近準備上線cassandra這個產品，同事在做一些小規格ECS(8G)的壓測。壓測時候比較容易觸發OOM Killer

Java堆外記憶體溢位問題排查，top命令下java服務res值上升

前幾天寫了一套java服務用於對接視訊單位的sdk介面，但是專案環境測試的時候出現了問題：          在linux環境下使用top命令檢視java命令的mem比值一直在緩慢的增加，第二天出現了服務宕機的情況，生成hs_err的log                 

Java堆外記憶體使用

JVM內部會把所有記憶體分成Java使用的堆記憶體和Native使用的記憶體，它們之間是不能共享的，就是說當你的Native記憶體用完了時，如果Java堆又有空閒記憶體，這時Native會重新向Jvm申請，而不是直接使用Java堆記憶體。 使用堆外記憶體，就是為了能直接分配和釋放記憶體，提高

Java——堆外記憶體詳解

記憶體是好東西，我們常聽堆記憶體，很多人卻不知道還有一個堆外記憶體。 那這兩個都是個啥玩意呢？且讓本帥博主今天給你好好說道說道。 一、堆內記憶體 那什麼東西是堆記憶體呢？我們來看看官方的說法。 “Java 虛擬機器具有一個堆(Heap)，堆是執行時資料區域，所

google-perftools 分析JAVA 堆外記憶體

原文轉自：http://koven2049.iteye.com/blog/1142768，所有權利歸原作者所有 最近線上執行的hbase發現分配了16g記憶體，但是實際使用了22g，堆外記憶體達到6g。感覺非常詭異。堆外記憶體用一般的工具很難檢視，可以通過google-pe

Netty之Java堆外記憶體掃盲貼

Java的堆外記憶體本來是高貴而神祕的東西，只在一些快取方案的收費企業版裡出現。但自從用了Netty，就變成了天天打交道的事情，畢竟堆外記憶體能減少IO時的記憶體複製，不需要堆記憶體Buffer拷貝一份到直接記憶體中，然後才寫入Socket中；而且也沒了煩人的GC。 好

Netty之Java堆外記憶體掃盲

Java的堆外記憶體本來是高貴而神祕的東西，只在一些快取方案的收費企業版裡出現。但自從用了Netty，就變成了天天打交道的事情，畢竟堆外記憶體能減少IO時的記憶體複製，不需要堆記憶體Buffer拷貝一份到直接記憶體中，然後才寫入Socket中；而且也沒了煩人的GC。 好

深入理解Java堆外記憶體

    關於堆記憶體(Heap)，相信作為 Java 開發者的你已經早有耳聞，但是，你瞭解堆外記憶體（Off Heap）嗎？  堆記憶體完全由 JVM 負責分配和釋放，如果程式存在缺陷，有可能導致記憶體洩漏而溢位，丟擲 OOM 異常： java.lang.OutOfMemor

java堆外記憶體

簡介 誰在使用堆外記憶體：執行緒棧，應用程式程式碼，NIO快取 什麼東西需要池化，昂貴的物件：執行緒，資料庫連線池, socket。 好處: 理論上能減少GC時間, 提高效率 JDK5.0之後，程式碼中能直接操作本地記憶體的方式有2種：使用未公開的Uns

java堆外記憶體洩漏

問題描述 最近有個系統在做壓力測試， 環境配置： 4核CPU 8g記憶體 jdk1.6.0_25，jvm配置-server -Xms2048m -Xmx2048m  出現問題如下 執行併發300人，壓測持續1個小時記憶體使用率從20%上升到100%,tps從11

java記憶體佔用異常問題常見排查流程（含堆外記憶體異常）

開發十年，就只剩下這套架構體系了！ >>>   

tsync堆外記憶體溢位排查經過

一、發生得問題 tsync服務總是莫名得宕機，java程序被莫名其妙的消失了。 二、查詢問題 當時看了系統日誌： sudo -u admin dmesg|grep -A20 kill screenshot 發現是oom了，記憶體不足被系統kill掉了。 當時懷疑有可能是堆內記憶體溢位，

Netty堆外記憶體洩露排查與總結

導讀 Netty 是一個非同步事件驅動的網路通訊層框架，用於快速開發高可用高效能的服務端網路框架與客戶端程式，它極大地簡化了 TCP 和 UDP 套接字伺服器等網路程式設計。 Netty 底層基於 JDK 的 NIO，我們為什麼不直接基於 JDK 的 NIO 或者其他NIO框架： 使用 JDK 自

後端---java中堆外記憶體詳解

堆外記憶體和堆內記憶體    堆外記憶體又稱為直接記憶體(Direct Memory)並不是虛擬機器執行時資料區的一部分,也不是Java虛擬機器規範中定義的記憶體區域.一直以來是Javaer們難以關注的一片領域,今天我們就一起探索一下這片區域究竟隱藏著什麼東東???? &

JAVA堆內記憶體、堆外記憶體

定義堆記憶體完全由JVM負責分配和釋放，如果程式碼有程式缺陷，可能是觸發OOM堆外記憶體為了能直接分配和釋放記憶體，提高效率。使用方式：使用未公開的Unsafe和NIO下的ByteBuffer堆外記憶體的回收機制Direct Memory是受GC控制的，例如ByteBuffe

java中使用堆外記憶體，關於記憶體回收需要注意的事和沒有解決的遺留問題(等大神解答)

JVM可以使用的記憶體分外2種：堆記憶體和堆外記憶體，堆記憶體完全由JVM負責分配和釋放，如果程式沒有缺陷程式碼導致記憶體洩露，那麼就不會遇到java.lang.OutOfMemoryError這個錯誤。使用堆外記憶體，就是為了能直接分配和釋放記憶體，提高效率。JDK5.

Java開發雜談（四）堆外記憶體

 JVM可以使用的記憶體分外兩種：堆記憶體和堆外記憶體。堆記憶體完全由JVM負責分配和釋放，堆外記憶體的存在是為了能直接分配和釋放記憶體，提高效率。 堆外記憶體優點： 對外記憶體由於避免了資料從使用者態向核心態的拷貝，提升IO效率，另外還可以節約大量的堆內記憶體，減少GC次數。

Spring Boot引起的“堆外記憶體洩漏”排查及經驗總結

背景 為了更好地實現對專案的管理，我們將組內一個專案遷移到MDP框架（基於Spring Boot），隨後我們就發現系統會頻繁報出Swap區域使用量過高的異常。筆者被叫去幫忙檢視原因，發現配置了4G堆內記憶體，但是實際使用的實體記憶體竟然高達7G，確實不正常。JVM引數配置是“-XX:MetaspaceSiz

Java使用JVM堆外記憶體

package com.company; import sun.misc.Unsafe; /** * Created by yellowboy on 2017/3/9. */ public class Main3 { public static void m