首页 ❯

监视 JVM 的非堆内存使用情况

performance memory java jvm
2022-09-01 02:10:53

我们通常处理由于堆或 permgen 大小配置问题而导致的 OutOfMemor 错误问题。

但所有的 JVM 内存都不是 permgen 或堆。据我所知，它也可以与线程/堆栈，本机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)

调谐

-Xms=6g
-Xms=6g
-XX:MaxPermSize=128m

-XX:-UseGCOverheadLimit
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:+CMSClassUnloadingEnabled

-XX:+OptimizeStringConcat
-XX:+UseCompressedStrings 
-XX:+UseStringCache

内存映射：

https://gist.github.com/slorber/5629214

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的交换
  • 交换度 = 0
  • 堆消耗似乎已适当调整
  • 在服务器上运行：只有Solr和一些监控的东西
  • 我们有一个正确的平均响应时间
  • 我们有时会有异常长的停顿，长达20秒

我猜暂停可能是交换堆上的完整GC，对吧？

为什么会有这么多的交换？

我甚至不知道这是进行服务器交换的JVM，还是我看不到的隐藏的东西。也许是操作系统页面缓存？但不确定为什么操作系统会创建页面缓存条目，如果这创建了交换。

我正在考虑测试一些流行的基于Java的存储/ NoSQL（如ElasticSearch，Voldemort或Cassandra）中使用的技巧：使用mlockall检查使JVM / Solr不交换mlockall

编辑：

在这里，您可以看到最大堆，已用堆（蓝色），已用交换（红色）。这似乎有点关系。

Swap and Heap

我可以看到Graphite经常发生许多ParNew GC。并且有一些CMS GC对应于图片的堆显着减少。

暂停似乎与堆减少无关，但通常分布在10：00和11：30之间，因此它可能与ParNew GC有关。

在负载测试期间，我可以看到一些光盘活动，还有一些交换IO活动，当测试结束时，这些活动非常平静。


答案 1

您的堆实际上正在使用 6.5 GB 的虚拟内存（这可能包括烫发代）

您有一堆使用 64 MB 堆栈的线程。不清楚为什么有些是，有些是默认的1 MB。

总共有 930 万 KB 的虚拟内存。我只会担心居民人数。

尝试 使用 来查找进程的常驻大小。top

您可能会发现此程序很有用

    BufferedReader br = new BufferedReader(new FileReader("C:/dev/gistfile1.txt"));
    long total = 0;
    for(String line; (line = br.readLine())!= null;) {
        String[] parts = line.split("[- ]");
        long start = new BigInteger(parts[0], 16).longValue();
        long end = new BigInteger(parts[1], 16).longValue();
        long size = end - start + 1;
        if (size > 1000000)
            System.out.printf("%,d : %s%n", size, line);
        total += size;
    }
    System.out.println("total: " + total/1024);

除非你有一个使用内存的JNI库，否则我的猜测是你有很多线程，每个线程都有自己的堆栈空间。我会检查你拥有的线程数。您可以减少每个线程的最大堆栈空间，但更好的选择可能是减少您拥有的线程数。

根据定义，堆外内存是非托管的，因此它不容易被“调整”。即使调整堆也不简单。

64 位 JVM 上的默认堆栈大小为 1024K，因此 700 个线程将使用 700 MB 的虚拟内存。

不应将虚拟内存大小与驻留内存大小混淆。64 位应用程序上的虚拟内存几乎是免费的，它只是您应该担心的驻留大小。

在我看来，你总共有9.3 GB。

  • 6.0 GB 堆。
  • 128 MB 烫发发电机
  • 700 MB 堆栈。
  • < 250 个共享库
  • 2.2 GB 的未知（我怀疑虚拟内存不是驻留内存）

上一次有人遇到这个问题时，他们的线程比他们应该的要多得多。我会检查您拥有的最大线程数，因为它是决定虚拟大小的峰值。例如，它是否接近3000？

嗯，这些对中的每一对都是一个线程。

7f0cffddf000-7f0cffedd000 rw-p 00000000 00:00 0 
7f0cffedd000-7f0cffee0000 ---p 00000000 00:00 0

这些表明您现在只有略少于700个线程.....


答案 2

虽然Lawrey先生非常详细地回答了你在哪里以及如何失去内存，但我相信有一些具体的步骤是有用的，比如（这样做，你就会知道你的java内存去了哪里）......

他的回答并没有真正帮助我解决类似的堆外内存使用问题，在我的情况下，这绝对不是线程问题。

enter image description here enter image description here

应用程序仅使用30mb的堆并且看起来非常健康，无缘无故地消耗了700%的堆。最终linux会杀死它，我不知道为什么，没有堆转储分析有助于日食内存分析器...

帮助我的工具叫做jxray。它不是免费的（没有什么好的），但它有一个试用版。

  1. 前往 https://jxray.com/download 并获取该工具
  2. 得到一个堆转储（是的，我知道你想要堆内存，但只是做）
  3. 生成报告./jxray.sh /path/to/dump

它将在你的内存转储旁边创建一个html文件报告，该报告必须总结出你的问题在哪里和哪里。

在我的情况下，它看起来像这样。

enter image description here

然后，您可以放大问题并查看其来源。显然，该工具足够智能，可以查看直接字节缓冲区的分配大小，以意识到应用程序使用的量远远超过堆转储中的使用量。

enter image description here

在我的情况下，我变得懒惰，并使用okhttp进行简单的长轮询http请求，这是这个小应用程序的全部目的。显然，它泄漏内存非常非常缓慢，我的应用程序每隔几周就会死一次。我摆脱了okhttp，将java升级到13并使用本机http客户端，现在一切正常，并且我的类路径中少了一个垃圾库。

我还建议您在健康的应用程序上使用它，非常确定您会发现一些您不知道的有趣事实）


推荐
更多 »
标签
更多 »
php pass-by-reference optional-parameters default-value javascript arrays dom function string object serialization tostring visibility syntax jslint use-strict operators equality equality-operator identity-operator datetime timestamp date-arithmetic redirect angularjs loops foreach iteration scope variables
推荐
更多 »