当前位置: 首页 > news >正文

记一次排查与解决docker容器(java程序)内存占用过大的问题

1、系统层面内存排查

1 docker stats查看容器使用总内存

通过docker stats [容器id]命令查看内存占用如下:

CONTAINER ID   NAME  CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O         PIDS
f414a2f20364   xxx   5.84%     38.19GiB / 123.2GiB   31.00%    1.34TB / 1.5TB   1.16GB / 29.8MB   354

2 在宿主机查看容器内存使用情况

1、通过ps -ef | grep [容器标识] 查询容器pid

root     12683     1  0 Feb11 ?        00:01:57 /usr/bin/containerd-shim-runc-v2 -namespace moby -id f414a2f203647ceab75bb4a1be3a1d0e5578eb14b9c1780810d6416c97bbdb86 -address /run/containerd/containerd.sock
  • 各列的解释:
    • UIDroot): 用户ID,表示运行该进程的用户。在你的输出中,root表示该进程是由root用户启动的。
    • PID12683): 进程ID,系统中每个进程的唯一标识符。
    • PPID236061): 父进程ID,PPID1,通常表示它是由init系统或Docker守护进程直接启动的。
    • C0): CPU使用率的简化表示,通常是进程的调度优先级。
    • STIME10:38Feb11): 进程启动时间或日期。 10:38表示当天的时间,而Feb11表示进程是在2月11日启动的。
    • TTY?): 终端类型,表示进程关联的终端。pts/2表示伪终端,通常是用户通过SSH或终端会话启动的。?表示没有关联的终端,通常是后台进程。
    • TIME00:00:0000:01:57):进程使用的累计CPU时间。
    • CMD: 启动进程的命令及其参数。
  • containerd-shim介绍:
    • /usr/bin/containerd-shim-runc-v2:这是可执行文件的路径,表示containerd的一个组件,负责管理容器的生命周期。
    • -namespace moby-namespace参数指定了容器所属的命名空间。在Docker中,moby通常是默认的命名空间,用于隔离不同的容器和资源。
    • -id f414a2f203647ceab75bb4a1be3a1d0e5578eb14b9c1780810d6416c97bbdb86-id参数指定了容器的完整ID。这个ID是容器的唯一标识符,用于管理和操作容器。
    • -address /run/containerd/containerd.sock-address参数指定了与containerd守护进程通信的Unix套接字地址。/run/containerd/containerd.sockcontainerd的默认套接字文件,用于进程间通信。

2、通过父进程pid找到容器内进程的pid: ps -ef | grep f414a2f20364

root     12683     1  0 Feb11 ?        00:01:57 /usr/bin/containerd-shim-runc-v2 -namespace moby -id f414a2f203647ceab75bb4a1be3a1d0e5578eb14b9c1780810d6416c97bbdb86 -address /run/containerd/containerd.sock
root     12742 12683  3 Feb11 ?        22:02:41 java -jar xxx.jar

3、top -p [pid1,pid2]查看真正内存占用

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                                               
12683 root      20   0  720048   8180   2888 S   0.0  0.0   1:57.85 containerd-shim                                                                                                                                       
12742 root      20   0   41.2g  27.9g   7008 S   0.0 22.6   1322:52 java 

3 内存显示不一致的问题

通过上述步骤,发现docker statstop所看到的内存不一致,原因如下:

docker stats显示的是整个容器的内存使用情况,包括所有进程的内存占用,还包括一些缓存和缓冲区的内存,这些在top中是不直接显示的。

4 排查容器的缓存占用

通过cgroup文件系统可以查看指定容器的内存使用情况:

  • cache:表示缓存的内存大小
  • rss:表示常驻内存大小。

1、方式1,在宿主机通过cgroup文件系统查看指定容器的内存使用情况。

cat /sys/fs/cgroup/memory/docker/容器id/memory.stat 

cache 20683264000
rss 29628477440
rss_huge 291504128
mapped_file 942080
swap 0
...

2、方式2,在容器内查看访问文件系统查看内存使用情况。

cat /sys/fs/cgroup/memory/memory.stat

cache 20683264000
rss 29629128704
rss_huge 291504128
mapped_file 1990656
swap 0
...

5 查看系统内存使用情况

无论在容器内外,使用cat /proc/meminfo命令,查看的都是当前宿主机的内存使用情况

cat /proc/meminfo

MemTotal:       129183640 kB
MemFree:          818860 kB
MemAvailable:   24080828 kB
Buffers:          180204 kB
Cached:         23378164 kB
SwapCached:            0 kB
Active:         113819220 kB
Inactive:       11582364 kB
Active(anon):   101853876 kB
Inactive(anon):    31492 kB
Active(file):   11965344 kB
Inactive(file): 11550872 kB
Unevictable:       10448 kB
...

2、jvm层面内存排查

1、查看堆内存情况

1、为docker赋予权限,使得容器内可以查看到宿主机的进程(不推荐,因为不安全)
docker run 添加--cap-add=SYS_PTRACE参数,或docker-compose添加如下参数:

version: "3"
services:
  xxx:
    image: xxx
    cap_add:
      - SYS_PTRACE

然后执行jmap -heap [pid],查看jvm使用情况

2、使用arthas查看(推荐)

curl -O https://arthas.aliyun.com/arthas-boot.jar
java -jar arthas-boot.jar
[arthas@1]$ dashboard 

Memory                                         used            total           max            usage           GC                                                                                                           
heap                                           7276M           20714M          27305M         26.65%          gc.ps_scavenge.count                                   9623                                                  
ps_eden_space                                  1174M           4067M           10203M         11.51%          gc.ps_scavenge.time(ms)                                1112280                                               
ps_survivor_space                              8M              8M              8M             96.63%          gc.ps_marksweep.count                                  42                                                    
ps_old_gen                                     6093M           16638M          20479M         29.76%          gc.ps_marksweep.time(ms)                               49463                                                 
nonheap                                        340M            352M            -1             96.49%                                                                                                                       
code_cache                                     155M            159M            240M           64.72%                                                                                                                       
metaspace                                      166M            173M            -1             95.86%                                                                                                                       
compressed_class_space                         18M             19M             1024M          1.83%                                                                                                                        
direct                                         263K            263K            -              100.00%                                                                                                                      
mapped                                         0K              0K              -              0.00%                                                                                                                        
                     

2、查看gc情况

root@f414a2f20364:/arthas# jstat -gcutil 1 1000
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   
 99.30   0.00   1.19  36.63  95.87  94.28   9625 1112.458    42   49.464 1161.923
 99.30   0.00   1.19  36.63  95.87  94.28   9625 1112.458    42   49.464 1161.923
 99.30   0.00   1.19  36.63  95.87  94.28   9625 1112.458    42   49.464 1161.923

3、查看jvm启动参数

添加--cap-add=SYS_PTRACE参数,执行如下命令:

root@f414a2f20364:/arthas#  jinfo 1

...
VM Flags:
Non-default VM flags: -XX:CICompilerCount=12 -XX:CMSFullGCsBeforeCompaction=3 -XX:CompressedClassSpaceSize=528482304 -XX:+HeapDumpOnOutOfMemoryError -XX:InitialHeapSize=2147483648 -XX:MaxHeapSize=8589934592 -XX:MaxMetaspaceSize=536870912 -XX:MaxNewSize=2863136768 -XX:MetaspaceSize=536870912 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=715653120 -XX:OldSize=1431830528 -XX:+UseCMSCompactAtFullCollection -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseParallelGC 
Command line:  -Xms2g -Xmx8g -XX:MaxMetaspaceSize=512m -XX:MetaspaceSize=512m -XX:+HeapDumpOnOutOfMemoryError -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=3

4、查看直接内存的使用情况

Native Memory Tracker默认是关闭的,需要添加jvm启动参数查看:-XX:NativeMemoryTracking=summary

jcmd [pid] VM.native_memory summary
root@663104c83c9e:/app# jcmd 1 VM.native_memory summary
1:

Native Memory Tracking:

Total: reserved=10191931KB, committed=3140431KB
-                 Java Heap (reserved=8388608KB, committed=2621952KB)
                            (mmap: reserved=8388608KB, committed=2621952KB) 
 
-                     Class (reserved=1119589KB, committed=78181KB)
                            (classes #11966)
                            (malloc=15717KB #17876) 
                            (mmap: reserved=1103872KB, committed=62464KB) 
 
-                    Thread (reserved=71121KB, committed=71121KB)
                            (thread #70)
                            (stack: reserved=70820KB, committed=70820KB)
                            (malloc=231KB #414) 
                            (arena=69KB #126)
 
-                      Code (reserved=253980KB, committed=29992KB)
                            (malloc=4380KB #6007) 
                            (mmap: reserved=249600KB, committed=25612KB) 
 
-                        GC (reserved=322636KB, committed=303188KB)
                            (malloc=16156KB #296) 
                            (mmap: reserved=306480KB, committed=287032KB) 
 
-                  Compiler (reserved=205KB, committed=205KB)
                            (malloc=63KB #668) 
                            (arena=142KB #15)
 
-                  Internal (reserved=16497KB, committed=16497KB)
                            (malloc=16465KB #16598) 
                            (mmap: reserved=32KB, committed=32KB) 
 
-                    Symbol (reserved=16233KB, committed=16233KB)
                            (malloc=14211KB #139114) 
                            (arena=2022KB #1)
 
-    Native Memory Tracking (reserved=2845KB, committed=2845KB)
                            (malloc=12KB #140) 
                            (tracking overhead=2833KB)
 
-               Arena Chunk (reserved=217KB, committed=217KB)
                            (malloc=217KB) 

3 结论

1、jvm内存未限制
2、容器缓存占用较高
3、未限制容器内存上限

4 内存限制

1 限制jvm内存

配置jvm启动参数:

command: java -Xms2g -Xmx8g -XX:MaxMetaspaceSize=512m -XX:MetaspaceSize=512m -XX:NativeMemoryTracking=summary -XX:+HeapDumpOnOutOfMemoryError -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=3 -jar xxx.jar

以下是你提供的JVM参数的解释:

  1. -Xms2g:设置JVM初始堆内存大小为2GB,这是JVM启动时分配的内存量。

  2. -Xmx8g:设置JVM最大堆内存大小为8GB,这是JVM可以使用的最大内存量。

  3. -XX:MaxMetaspaceSize=512m:设置元空间(Metaspace)的最大大小为512MB,元空间用于存储类元数据。

  4. -XX:MetaspaceSize=512m: 设置元空间的初始大小为512MB,JVM会根据需要动态调整元空间的大小。

  5. -XX:NativeMemoryTracking=summary:启用本地内存跟踪(Native Memory Tracking, NMT),并设置为摘要模式,NMT用于监控JVM的本地内存使用,帮助诊断内存泄漏和优化内存使用。

  6. -XX:+HeapDumpOnOutOfMemoryError:启用此选项会在发生内存溢出错误时生成堆转储文件,便于后续分析和调试。

  7. -XX:+UseCMSCompactAtFullCollection:在使用CMS(Concurrent Mark-Sweep)垃圾收集器时,启用在Full GC后进行内存压缩,以减少内存碎片。

  8. -XX:CMSFullGCsBeforeCompaction=3: 设置在进行3次Full GC后进行一次内存压缩。这与UseCMSCompactAtFullCollection结合使用,帮助减少内存碎片。

2 清理宿主机cache

将所有未写的系统缓冲区写到磁盘中,包含已修改的i-node、已延迟的块I/O和读写映射文件,同时清除pagecache和slab分配器中的缓存对象。

sync; echo 3 > /proc/sys/vm/drop_caches

3 限制容器自身内存使用

version: "3"
services:
  xxx:
    deploy:
      resources:
        limits:
          memory: 10G

参考

1、如何查看jvm堆外内存使用情况? - 架构师专栏的回答 - 知乎
2、聊聊docker容器的memory限制
3、如何通过docker-compose对docker容器资源进行限制
4、浅谈dockerd、contaierd、containerd-shim、runC之间的关系
5、Docker容器的基础使用方法总结【八】——docker资源限制
6、Linux中buff-cache占用过高解决方案
7、查看docker容器的内存占用

相关文章:

  • 【蓝桥杯速成】| 1.暴力解题
  • 深入理解 HTML 链接:网页导航的核心元素
  • 前端npm包- CropperJS
  • 鸿蒙路由 HMrouter 配置及使用一
  • 凝思linux修改mac地址
  • Spring Boot 约定大于配置:实现自定义配置
  • 山东省新一代信息技术创新应用大赛-计算机网络管理赛项(样题)
  • Epoch 和 Batch Size的设计 + 模型的早停策略(基于上篇)
  • [目标检测] 训练之前要做什么
  • 高效办公利器:深入解析FastExcel如何读写Excel文件
  • 【Visio使用教程】
  • 机器学习之向量化
  • 【第8章】亿级电商平台订单系统-技术选型
  • 每日一题--面试
  • c#面试题整理12
  • WordPress the_category与single_cat_title的区别
  • php-fpm.log文件过大导致磁盘空间跑满及php-fpm无法重启问题处理
  • Linux——信号
  • DHCP中继实验
  • 设计模式--单例模式(Singleton)【Go】
  • 加强社区网站建设/西安优化外
  • 网址导航主页/优化落实疫情防控新十条
  • 美国最大的vps网站/百度图片识别
  • 聊城网站建设培训班/本地推广平台有哪些
  • asp.net网站开发上/seo关键词优化推广价格
  • 婚纱网站模板/创建自己的网站