高併發多線程下的內存泄漏問題檢查

好久沒有寫文章了,主要是很擔心觸碰公司高壓線,其次是真的很忙。。。這篇文章改了好幾次,把敏感信息全部去掉纔敢發出來。

現象:應用的內存在高併發下內存持續增加,具體體現在早上7點,每秒處理2W,內存增長趨勢很快,分配給應用的內存最大值爲4G,但是實際上容器節點的內存使用率早已超過這個值,

通過top命令看到的內存使用並不高,略高於4G,初步懷疑是容器統計有問題,看了下內存的狀態信息

cat /sys/fs/cgroup/memory/memory.stat

因爲安全保密緣故,以下數據爲例子數據,不是真實數據
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

看了下內存信息 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導致內存使用統計有問題,但是看到rss很高可以確定不是cache造成的統計錯誤。

rss很高的情況下,只有java應用在跑着。

導出來的jmap堆棧:

jmap -dump:format=b,file=20210508heapdump.hprof pid

並沒有分析出具體的原因,只知道是加載器加載了大量的線程對象,這些對象都不大,但是量多。

這個時候想了下去拿內存裏面的信息看看吧,也懷疑是不是堆外內存在增長。

使用pmap查看進程的內存分配

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 ]


發現很多RSS大小爲40-160的內存段,至少有2W個,這是及其不正常的,理論上是不應該有這麼多的。

這個時候用smaps可以輸出進程使用的內存塊詳細信息,包括地址範圍和來源

cat /proc/<pid>/smaps > 20210508smaps.txt
注:因爲安全保密緣故,以下數據爲例子數據,不是真實數據

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,找到有問題的內存塊地址,先從pmap中找到有問題的地址,比如Address爲000000080241e000的有問題,則拿着80241e000去smaps找到對應的地址段, 一般會有連續的一個地址段,找問題對應的size,因爲連續的地址段可能存在別的內存數據,但是肯定在前後,只需要size對應上就大概率是這個內存段數據。

假設現在找到有問題的地址段爲:

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 

這個時候找到了內存的地址段 ,就需要獲取這個內存地址段上的數據,使用gdb神器。

gdb attach PID

這個時候會刷一大串代碼,進入gdb命令行,在gdb下將上面找到的內存段信息dump下來。

dump memory /tmp/20210508.dump 0x80241e000 0x802420000

這個時候在 /tmp/20210508.dump 可以找到該內存段數據,可以自己用vim或者less慢慢找,也可以偷懶使用strings命令來幫忙找關鍵字。

顯示長度超過8個字符的字符串。

strings -8 /tmp/20210508.dump

找到之後使用關鍵字再用less命令去文件裏查找。

這時候大概能看到一串這樣的字符

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
insert xxx value(123,456,789) @@@@
https://qq.com,@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

看起來這個內存地址段記錄的數據是某方法在寫入一個表的時候的操作,這是我們應用某個方法塊的數據,找到對應的方法塊上下文調用查了下,發現了問題的所在,這個方法被調用的地方在局部new了一個線程池,線程池並沒有做shutdown操作,導致大量的線程雖然執行好了但是在存在,所以內存一直在增長。

到了這裏問題基本上知道怎麼解決了,將線程池扔出外面去,不要在局部new線程池,編譯發佈,高併發模擬測試,內存不再增長。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章