背景

最近準(zhǔn)備上線cassandra這個(gè)產(chǎn)品，同事在做一些小規(guī)格ECS(8G)的壓測(cè)。壓測(cè)時(shí)候比較容易觸發(fā)OOM Killer，把cassandra進(jìn)程干掉。問(wèn)題是8G這個(gè)規(guī)格我配置的heap(Xmx)并不高（約6.5g）已經(jīng)留出了足夠的空間給系統(tǒng)。只有可能是Java堆外內(nèi)存使用超出預(yù)期，導(dǎo)致RES增加，才可能觸發(fā)OOM。

調(diào)查過(guò)程

0.初步懷疑是哪里有DirectBuffer泄漏，或者JNI庫(kù)的問(wèn)題。
1.按慣例通過(guò)google perftools追蹤堆外內(nèi)存開(kāi)銷(xiāo)，但是并未發(fā)現(xiàn)明顯的異常。
2.然后用Java NMT 看了一下，也沒(méi)有發(fā)現(xiàn)什么異常。

?

3.查到這里思路似乎斷了，因?yàn)楦鶧irectBuffer似乎沒(méi)啥關(guān)系。這時(shí)候我注意到進(jìn)程虛擬內(nèi)存非常高，已經(jīng)超過(guò)ECS內(nèi)存了。懷疑這里有些問(wèn)題。

?

4.進(jìn)一步通過(guò)/proc/pid/smaps 查看進(jìn)程內(nèi)存地址空間分布，發(fā)現(xiàn)有大量mmap的文件。這些文件是cassandra的數(shù)據(jù)文件。

?

此時(shí)這些mmap file 虛擬內(nèi)存是2G，但是物理內(nèi)存是0（因?yàn)槲抑爸貑⑦^(guò)，調(diào)低過(guò)內(nèi)存防止進(jìn)程掛掉影響問(wèn)題排查）。

顯然mmap的內(nèi)存開(kāi)銷(xiāo)是不受JVM heap控制的，也就是堆外內(nèi)存。如果mmap的文件數(shù)據(jù)被從磁盤(pán)load進(jìn)物理內(nèi)存(RES增加)，Java NMT和google perftool是無(wú)法感知的，這是kernel的調(diào)度過(guò)程。

5.考慮到是在壓測(cè)時(shí)候出現(xiàn)問(wèn)題的，所以我只要讀一下這些文件，觀察下RES是否會(huì)增加，增加多少，為啥增加，就能推斷問(wèn)題是不是在這里。通過(guò)下面的命令簡(jiǎn)單讀一下之前導(dǎo)入的數(shù)據(jù)。

cassandra-stress read duration=10m cl=ONE -rate threads=20 -mode native cql3 user=cassandra password=123 -schema keysp ace=keyspace5 -node core-3

6.可以觀察到壓測(cè)期間(sar -B)，major page fault是明顯上升的，因?yàn)閿?shù)據(jù)被實(shí)際從磁盤(pán)被load進(jìn)內(nèi)存。

同時(shí)觀察到mmap file物理內(nèi)存增加到20MB:

最終進(jìn)程RES漲到7.1g左右，增加了大約600M:

?

如果加大壓力（50線程），還會(huì)漲，每個(gè)mmap file物理內(nèi)存會(huì)從20MB，漲到40MB

7.Root cause是cassandra識(shí)別系統(tǒng)是64還是32來(lái)確定要不要用mmap，ECS都是64，但是實(shí)際上小規(guī)格ECS內(nèi)存并不多。

?

結(jié)論

1.問(wèn)題誘因是mmap到內(nèi)存開(kāi)銷(xiāo)沒(méi)有考慮進(jìn)去，具體調(diào)整方法有很多。可以針對(duì)小規(guī)格ECS降低heap配置或者關(guān)閉mmap特性(disk_access_mode=standard)

2.排查Java堆外內(nèi)存還是比較麻煩的，推薦先用NMT查查，用起來(lái)比較簡(jiǎn)單，配置JVM參數(shù)即可，可以看到內(nèi)存申請(qǐng)情況。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的Cassandra Java堆外内存排查经历全记录的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。