当前设置:
- Java应用程序在Google Kubernetes引擎上作为Kubernetes工作负载运行
- JVM参数:“-XX:+缓存ContainerSupport”,“-XX:NativeMemoryTracking=detail”,“-XX:+HeapDumpOnOutOfMemoryError”,“-XX:HeapDumpPath=/dumps/oom.bin”,“-Xmx300m”,“-Xms300m”
1.使用deployment.yml设置Docker内存
limits:cpu:350m memory:700Mi requests:cpu:200m memory:128Mi
1.当pod非常接近最大容器限制时,提交的本机内存低于550 m。这使我相信除了本机内存之外还有其他原因导致此问题
总计:保留= 1788920 KB,提交= 546092 KB- Java堆(保留= 307200 KB,提交= 307200 KB)(mmap:保留= 307200 KB,提交= 307200 KB)
- Class (reserved=1116111KB, committed=75431KB)
(classes #12048)
(malloc=1999KB #25934)
(mmap: reserved=1114112KB, committed=73432KB)
- Thread (reserved=46444KB, committed=46444KB)
(thread #46)
(stack: reserved=46240KB, committed=46240KB)
(malloc=153KB #270)
(arena=51KB #88)
- Code (reserved=259362KB, committed=57214KB)
(malloc=9762KB #14451)
(mmap: reserved=249600KB, committed=47452KB)
- GC (reserved=1034KB, committed=1034KB)
(malloc=26KB #180)
(mmap: reserved=1008KB, committed=1008KB)
- Compiler (reserved=321KB, committed=321KB)
(malloc=189KB #982)
(arena=133KB #5)
- Internal (reserved=39461KB, committed=39461KB)
(malloc=39429KB #16005)
(mmap: reserved=32KB, committed=32KB)
- Symbol (reserved=15588KB, committed=15588KB)
(malloc=13214KB #128579)
(arena=2374KB #1)
- Native Memory Tracking (reserved=3220KB, committed=3220KB)
(malloc=249KB #3553)
(tracking overhead=2971KB)
- Arena Chunk (reserved=178KB, committed=178KB)
(malloc=178KB)
字符串
1.还使用ps(550 m)和htop(res 604 m)检查了java进程的内存消耗
问题
pod有一个容器,该容器只有这个java应用程序运行上述的pod。这个java应用程序本质上是使用线程并行下载图像,并进行一些验证,如图像大小,维度等。pod内存消耗不断增加,直到它几乎达到该限制,应用程序重新启动。我读过许多不同的帖子和文章,我不知道是什么原因导致这一点内存继续上升。
编辑1:Docker镜像基于openjdk:8-jdk-slim编辑2:监控x1c 0d1xx 1c 1d 1xx 1c 2d 1x的一些截图
1条答案
按热度按时间nwlls2ji1#
我们在GKE上使用Java时遇到了完全相同的问题,在我们的例子中,Sping Boot 服务器运行在Alpine Linux容器中。问题不在Java代码中,而是在Java VM本身:在Linux上,它无法处理分配然后释放大量内存的多线程应用程序。幸运的是有一个解决方案:jemalloc。假设你使用的是Alpine,只需将以下内容添加到你的Dockerfile:
字符串
问题解决了。它把我们的Sping Boot 容器从3.5GB降到了2.6GB。
如果由于某种原因上述操作很困难,请尝试设置MALLESS_竞技场_MAX=4(或2)。