我們通常處理OutOfMemoryError問題，因為堆或permgen大小配置問題。

但是所有的JVM內存不是permgen或者heap。

據我所知，它也可以與Threads / Stacks，本地JVM代碼相關…

但是使用pmap我可以看到進程分配了9.3G這是3.3G堆外內存使用。

我不知道什么是監視和調整這種額外的堆外內存消耗的可能性。

我不使用直接的離堆內存訪問(MaxDirectMemorySize是64m默認)

Context: Load testing

Application: Solr/Lucene server

OS: Ubuntu

Thread count: 700

Virtualization: vSphere (run by us, no external hosting)

JVM

java version "1.7.0_09"

Java(TM) SE Runtime Environment (build 1.7.0_09-b05)

Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)

Tunning

-Xms=6g

-Xms=6g

-XX:MaxPermSize=128m

-XX:-UseGCOverheadLimit

-XX:+UseConcMarkSweepGC

-XX:+UseParNewGC

-XX:+CMSClassUnloadingEnabled

-XX:+OptimizeStringConcat

-XX:+UseCompressedStrings

-XX:+UseStringCache

內存映射：

vmstat

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----

r b swpd free buff cache si so bi bo in cs us sy id wa

1 0 1743 381 4 1150 1 1 60 92 2 0 1 0 99 0

自由

total used free shared buffers cached

Mem: 7986 7605 381 0 4 1150

-/+ buffers/cache: 6449 1536

Swap: 4091 1743 2348

最佳

top - 11:15:49 up 42 days, 1:34, 2 users, load average: 1.44, 2.11, 2.46

Tasks: 104 total, 1 running, 103 sleeping, 0 stopped, 0 zombie

Cpu(s): 0.5%us, 0.2%sy, 0.0%ni, 98.9%id, 0.4%wa, 0.0%hi, 0.0%si, 0.0%st

Mem: 8178412k total, 7773356k used, 405056k free, 4200k buffers

Swap: 4190204k total, 1796368k used, 2393836k free, 1179380k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

17833 jmxtrans 20 0 2458m 145m 2488 S 1 1.8 206:56.06 java

1237 logstash 20 0 2503m 142m 2468 S 1 1.8 354:23.19 java

11348 tomcat 20 0 9184m 5.6g 2808 S 1 71.3 642:25.41 java

1 root 20 0 24324 1188 656 S 0 0.0 0:01.52 init

2 root 20 0 0 0 0 S 0 0.0 0:00.26 kthreadd

...

df – > tmpfs

Filesystem 1K-blocks Used Available Use% Mounted on

tmpfs 1635684 272 1635412 1% /run

我們的主要問題：

>服務器有8G的物理內存

> Solr的堆只有6G

>有1.5G的交換

> Swappiness = 0

>堆消耗似乎適當調整

>在服務器上運行：只有Solr和一些監視的東西

>我們有一個正確的平均響應時間

>我們有時會有長時間停頓，長達20秒

我想暫停可能是一個完整的GC上交換堆右？

為什么有這么多的互換？

我甚至不知道這是否是使服務器交換的JVM，或者如果它是隱藏的，我看不到的東西。也許操作系統頁面緩存？但不知道為什么操作系統將創建頁面緩存條目，如果創建交換。

我正在考慮測試mlockall技巧用于一些流行的基于Java的存儲/ NoSQL像ElasticSearch，Voldemort或Cassandra：check Make JVM/Solr not swap, using mlockall

編輯：

在這里你可以看到最大堆，使用堆(藍色)，使用的交換(紅色)。它似乎是相關的。

我可以看到與Graphite有很多ParNew GC定期發生。而且有一些CMS GC對應于堆圖像的顯著減少。

暫停似乎不與堆減少相關，但是在10:00和11:30之間有規律地分布，因此它可能與ParNew GC有關。

在負載測試期間，我可以看到一些光盤活動以及一些交換IO活動，這是真的平靜的，當測試結束。

總結

以上是生活随笔為你收集整理的java非堆内存_java – 监视JVM的非堆内存使用情况的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。