本篇內(nèi)容介紹了“如何檢查高并發(fā)多線程下的內(nèi)存泄漏問題”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠?qū)W有所成!
成都創(chuàng)新互聯(lián)公司專注于企業(yè)營銷型網(wǎng)站建設、網(wǎng)站重做改版、源匯網(wǎng)站定制設計、自適應品牌網(wǎng)站建設、H5開發(fā)、成都做商城網(wǎng)站、集團公司官網(wǎng)建設、成都外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應式網(wǎng)頁設計等建站業(yè)務,價格優(yōu)惠性價比高,為源匯等各大城市提供網(wǎng)站開發(fā)制作服務。
現(xiàn)象:應用的內(nèi)存在高并發(fā)下內(nèi)存持續(xù)增加,具體體現(xiàn)在早上7點,每秒處理2W,內(nèi)存增長趨勢很快,分配給應用的內(nèi)存最大值為4G,但是實際上容器節(jié)點的內(nèi)存使用率早已超過這個值,
通過top命令看到的內(nèi)存使用并不高,略高于4G,初步懷疑是容器統(tǒng)計有問題,看了下內(nèi)存的狀態(tài)信息
cat /sys/fs/cgroup/memory/memory.stat
因為安全保密緣故,以下數(shù)據(jù)為例子數(shù)據(jù),不是真實數(shù)據(jù) cache 148365312 rss 5496782848 rss_huge 0 mapped_file 1605632 swap 0 pgpgin 3524638 pgpgout 2146428 pgfault 9691132 pgmajfault 44 inactive_anon 1142784 active_anon 5496709120 inactive_file 104824832 active_file 42397696 unevictable 0 hierarchical_memory_limit 8523934592 hierarchical_memsw_limit 8523934592 total_cache 148365312 total_rss 5492382848 total_rss_huge 0 total_mapped_file 1605632 total_swap 0 total_pgpgin 3524638 total_pgpgout 2146428 total_pgfault 9691132 total_pgmajfault 44 total_inactive_anon 1142784 total_active_anon 5423709120 total_inactive_file 104823832 total_active_file 42397696 total_unevictable 0
看了下內(nèi)存信息 cat /sys/fs/cgroup/memory/memory.meminfo
MemTotal: 8382308 kB MemFree: 2874740 kB Buffers: 0 kB Cached: 145000 kB SwapCached: 0 kB Active: 5412308 kB Inactive: 103516 kB Active(anon): 5323724 kB Inactive(anon): 1116 kB Active(file): 41484 kB Inactive(file): 102400 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 5362300 kB Mapped: 1568 kB Shmem: 0 kB Slab: 0 kB SReclaimable: 0 kB SUnreclaim: 0 kB KernelStack: 0 kB PageTables: 0 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 0 kB Committed_AS: 0 kB VmallocTotal: 0 kB VmallocUsed: 0 kB VmallocChunk: 0 kB HardwareCorrupted: 0 kB AnonHugePages: 0 kB
確實rss有點高
ps -p PID -o rss,vsz
rss特別高,一開始以為是cache導致內(nèi)存使用統(tǒng)計有問題,但是看到rss很高可以確定不是cache造成的統(tǒng)計錯誤。
rss很高的情況下,只有java應用在跑著。
導出來的jmap堆棧:
jmap -dump:format=b,file=20210508heapdump.hprof pid
并沒有分析出具體的原因,只知道是加載器加載了大量的線程對象,這些對象都不大,但是量多。
這個時候想了下去拿內(nèi)存里面的信息看看吧,也懷疑是不是堆外內(nèi)存在增長。
使用pmap查看進程的內(nèi)存分配
pmap -x PID > 20210508pmap.txt Address Kbytes RSS Dirty Mode Mapping 0000000700000000 4194304 4167772 4167772 rw--- [ anon ] 0000000800000000 7180 5284 0 r---- classes.jsa 0000000800703000 9204 0 0 ----- [ anon ] 0000000801000000 10996 5556 5196 rw--- classes.jsa 0000000801abd000 5388 0 0 ----- [ anon ] 0000000802000000 1552 1540 176 rw--- classes.jsa 0000000802184000 2544 0 0 ----- [ anon ] 0000000802400000 36 20 0 r-x-- classes.jsa 0000000802409000 84 0 0 ----- [ anon ] 000000080241e000 10240 10172 10172 rw--- [ anon ] 0000000802e1e000 1038336 0 0 ----- [ anon ] 00007fdebc000000 132 12 12 rw--- [ anon ] 00007fdebc021000 65404 0 0 ----- [ anon ] 00007fdec4000000 132 4 4 rw--- [ anon ] 00007fdec4021000 65404 0 0 ----- [ anon ] 00007fdec8000000 132 4 4 rw--- [ anon ] 00007fdec8021000 65404 0 0 ----- [ anon ] 00007fdecc000000 132 4 4 rw--- [ anon ]
發(fā)現(xiàn)很多RSS大小為40-160的內(nèi)存段,至少有2W個,這是及其不正常的,理論上是不應該有這么多的。
這個時候用smaps可以輸出進程使用的內(nèi)存塊詳細信息,包括地址范圍和來源
cat /proc/<pid>/smaps > 20210508smaps.txt 注:因為安全保密緣故,以下數(shù)據(jù)為例子數(shù)據(jù),不是真實數(shù)據(jù) 802300000-80211000 r-xp 01345000 fc:10 13514 Size: 36 kB Rss: 20 kB Pss: 20 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 20 kB Private_Dirty: 0 kB Referenced: 20 kB Anonymous: 0 kB AnonHugePages: 0 kB Swap: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 0 kB VmFlags: rd ex mr mw me 803609000-80291e000 ---p 00000000 00:00 0 Size: 84 kB Rss: 0 kB Pss: 0 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 0 kB Referenced: 0 kB Anonymous: 0 kB AnonHugePages: 0 kB Swap: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 0 kB VmFlags: mr mw me nr
查看smaps.txt,找到有問題的內(nèi)存塊地址,先從pmap中找到有問題的地址,比如Address為000000080241e000
的有問題,則拿著80241e000
去smaps找到對應的地址段, 一般會有連續(xù)的一個地址段,找問題對應的size,因為連續(xù)的地址段可能存在別的內(nèi)存數(shù)據(jù),但是肯定在前后,只需要size對應上就大概率是這個內(nèi)存段數(shù)據(jù)。
假設現(xiàn)在找到有問題的地址段為:
80241e000-802420000 ---p 00000000 00:00 0 Size: 1540 kB Rss: 1540 kB Pss: 0 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 0 kB Referenced: 0 kB Anonymous: 0 kB AnonHugePages: 0 kB Swap: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 0 kB VmFlags: mr mw me nr
這個時候找到了內(nèi)存的地址段 ,就需要獲取這個內(nèi)存地址段上的數(shù)據(jù),使用gdb
神器。
gdb attach PID
這個時候會刷一大串代碼,進入gdb命令行,在gdb下將上面找到的內(nèi)存段信息dump下來。
dump memory /tmp/20210508.dump 0x80241e000 0x802420000
這個時候在 /tmp/20210508.dump
可以找到該內(nèi)存段數(shù)據(jù),可以自己用vim或者less慢慢找,也可以偷懶使用strings
命令來幫忙找關鍵字。
顯示長度超過8個字符的字符串。
strings -8 /tmp/20210508.dump
找到之后使用關鍵字再用less命令去文件里查找。
這時候大概能看到一串這樣的字符
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ insert xxx value(123,456,789) @@@@ https://qq.com,@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
看起來這個內(nèi)存地址段記錄的數(shù)據(jù)是某方法在寫入一個表的時候的操作,這是我們應用某個方法塊的數(shù)據(jù),找到對應的方法塊上下文調(diào)用查了下,發(fā)現(xiàn)了問題的所在,這個方法被調(diào)用的地方在局部new了一個線程池,線程池并沒有做shutdown操作,導致大量的線程雖然執(zhí)行好了但是在存在,所以內(nèi)存一直在增長。
到了這里問題基本上知道怎么解決了,將線程池扔出外面去,不要在局部new線程池,編譯發(fā)布,高并發(fā)模擬測試,內(nèi)存不再增長。
“如何檢查高并發(fā)多線程下的內(nèi)存泄漏問題”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注創(chuàng)新互聯(lián)網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實用文章!
網(wǎng)站題目:如何檢查高并發(fā)多線程下的內(nèi)存泄漏問題
網(wǎng)頁路徑:http://bm7419.com/article14/jdjcge.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供微信小程序、App設計、網(wǎng)站導航、微信公眾號、Google、ChatGPT
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)