相关疑难解决方法(0)

对于我的应用程序,Java进程使用的内存远远超过堆大小.

容器正在运行的系统开始出现内存问题,因为容器占用的内存比堆大小多得多.

堆大小设置为128 MB(-Xmx128m -Xms128m),而容器最多占用1 GB内存.在正常情况下,它需要500MB.如果docker容器具有以下限制(例如mem_limit=mem_limit=400MB),则该进程被OS的内存不足杀死所杀死.

你能解释为什么Java进程使用比堆更多的内存吗？如何正确调整Docker内存限制？有没有办法减少Java进程的堆外内存占用？

我使用JVM中的本机内存跟踪命令收集有关该问题的一些详细信息.

从主机系统,我获得容器使用的内存.

$ docker stats --no-stream 9afcb62a26c8
CONTAINER ID        NAME                                                                                        CPU %               MEM USAGE / LIMIT   MEM %               NET I/O             BLOCK I/O           PIDS
9afcb62a26c8        xx-xxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.0acbb46bb6fe3ae1b1c99aff3a6073bb7b7ecf85   0.93%               461MiB / 9.744GiB   4.62%               286MB / 7.92MB      157MB / 2.66GB      57

从容器内部,我获得进程使用的内存.

$ ps -p 71 -o pcpu,rss,size,vsize
%CPU   RSS  SIZE    VSZ
11.2 486040 580860 3814600

$ jcmd 71 VM.native_memory
71:

Native Memory Tracking:

Total: reserved=1631932KB, committed=367400KB
-                 Java Heap (reserved=131072KB, …

在运行启用了本机内存跟踪的Java应用程序(在YARN中)时(-XX:NativeMemoryTracking=detail请参阅https://docs.oracle.com/javase/8/docs/technotes/guides/vm/nmt-8.html和https:// docs. oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html),我可以看到JVM在不同类别中使用了多少内存.

我在jdk 1.8.0_45上的应用程序显示:

Native Memory Tracking:

Total: reserved=4023326KB, committed=2762382KB
-                 Java Heap (reserved=1331200KB, committed=1331200KB)
                            (mmap: reserved=1331200KB, committed=1331200KB) 

-                     Class (reserved=1108143KB, committed=64559KB)
                            (classes #8621)
                            (malloc=6319KB #17371) 
                            (mmap: reserved=1101824KB, committed=58240KB) 

-                    Thread (reserved=1190668KB, committed=1190668KB)
                            (thread #1154)
                            (stack: reserved=1185284KB, committed=1185284KB)
                            (malloc=3809KB #5771) 
                            (arena=1575KB #2306)

-                      Code (reserved=255744KB, committed=38384KB)
                            (malloc=6144KB #8858) 
                            (mmap: reserved=249600KB, committed=32240KB) 

-                        GC (reserved=54995KB, committed=54995KB)
                            (malloc=5775KB #217) 
                            (mmap: reserved=49220KB, committed=49220KB) 

-                  Compiler (reserved=267KB, committed=267KB)
                            (malloc=137KB #333) 
                            (arena=131KB #3)

-                  Internal (reserved=65106KB, committed=65106KB)
                            (malloc=65074KB …

我们有什么 :

• 在docker容器中运行的Java应用程序
• 没有调用本机代码,没有处理启动,没有引用DLL/.so文件.
• JVM args: -Xmx256m -XX:NativeMemoryTracking=summary
• Docker硬内存限制设置为 768m
• JVM似乎正常(正常的GC循环,没有内存泄漏,没有OOM)
• Docker内存不断增长,直到达到硬限制(768m),导致杀死并重新启动容器.

问题 :

• 为什么Docker统计数据内存不断增长(导致每天都会遇到硬内存限制),尽管JVM似乎表现在其极限范围内.

• 使用其他微服务,我们看不到这种行为

JVM

在JVM方面,我们没有注意到任何特殊的东西:

Docker统计输出:

492.8MiB / 768MiB     64.17%              

[ec2-user@ip-10-180-28-222 ~]$ docker exec 34d7 jcmd 1 VM.native_memory summary
1:

Native Memory Tracking:

Total: reserved=1731355KB, committed=472227KB
-                 Java Heap (reserved=262144KB, committed=262144KB)
                            (mmap: reserved=262144KB, committed=262144KB)

-                     Class (reserved=1131805KB, committed=92829KB)
                            (classes #16224)
                            (malloc=7453KB #20996)
                            (mmap: reserved=1124352KB, committed=85376KB)

-                    Thread (reserved=29932KB, committed=29932KB)
                            (thread #30)
                            (stack: reserved=29772KB, committed=29772KB)
                            (malloc=94KB #151)
                            (arena=66KB #55)

-                      Code (reserved=255659KB, committed=35507KB)
                            (malloc=6059KB #9814)
                            (mmap: …

我们最近对生产系统的观察告诉我们Java容器的驻留内存使用量增长了.关于这个问题,我们已经做了一些调查,以了解为什么java进程使用像pmap这样的本机工具消耗比Heap + Thread Stacks + Shared Objects + Code Cache +等更多的内存.结果,我们发现了一些由本机进程分配的64M内存块(成对)(可能使用malloc/mmap):

0000000000400000      4K r-x--  /usr/java/jdk1.7.0_17/bin/java
0000000000600000      4K rw---  /usr/java/jdk1.7.0_17/bin/java
0000000001d39000   4108K rw---    [ anon ]
0000000710000000  96000K rw---    [ anon ]
0000000715dc0000  39104K -----    [ anon ]
00000007183f0000 127040K rw---    [ anon ]
0000000720000000 3670016K rw---    [ anon ]
00007fe930000000  62876K rw---    [ anon ]
00007fe933d67000   2660K -----    [ anon ]
00007fe934000000  20232K rw---    [ anon ]
00007fe9353c2000  45304K -----    [ anon ]
00007fe938000000  65512K rw---    [ anon ]
00007fe93bffa000 …

我在尝试分析在 docker 容器与主机上运行的 Java 应用程序中的内存消耗时遇到了一个有趣的问题。

1. Java 应用程序是 Jetty 服务器 9.4.9 上的 Web 应用程序
2. Java 版本：1.8
3. 主机：MAC
4. Docker 镜像：jetty:9.4-jre8
5. docker 守护进程是 18.03.1-ce 版本。

在主机上，我使用 Yourkit 工具来分析内存消耗。

对于 docker 容器 docker stats <docker id/name>

我得到的是，在 MAC yourkit 上显示了 50M 非堆大小 + ~40M 堆大小，总共 ~ 100M

然而，当我在容器上部署和运行相同的战争时，统计数据显示为200M

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
879fb113ca8d        jetty-app           0.19%               214.6MiB / 1.952GiB   10.74%              1.49MB / 88.9kB     31.7MB / 6.42MB     29

任何人都可以对这种现象有所了解吗？

假设stats提供了错误的结果，我尝试使用--memory …

我有一个运行带有以下jvm参数的java应用程序的容器:

-XX:+UseG1GC -Xms512m -Xmx2048m -XX:MaxPermSize=256m

我正在使用docker内存限制选项:

docker run -it -m 2304m foo bash

docker stats myApp在容器初始化之后运行会给我:

CONTAINER   CPU %    MEM USAGE/LIMIT     MEM %   NET I/O
myApp       0.17%  660.5 MB/2.416 GB    27.34%   240.8 kB/133.4 kB

但几个小时后我得到以下统计数据:

CONTAINER   CPU %    MEM USAGE/LIMIT     MEM %   NET I/O
myApp     202.18%  2.416 GB/2.416 GB   100.00%   27.67 GB/19.49 GB

虽然,如果我查看容器内正在运行的应用程序的进程执行细节,我有一个用法,~735MBmyApp继续计算请求没有任何问题:

me@docker-container ~]$ ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
me+          1  0.0  0.0  11636  1324 ?        Ss …