在对运行在ECS/EC2/Docker/Centos7 7/Tomcat/OpenJDK8 8环境中的Java应用程序进行性能测试时,我观察到JVM内存出现了一个大的、离散的尖峰。
性能测试非常简单,它包括对位于由弹性容器服务管理的EC2主机上运行的一对码头容器的AWS应用程序负载均衡器的连续并发请求。通常,并发级别为30个同时负载测试客户端连接/线程。几分钟内,码头集装箱中的一个通常会受到影响。
内存尖峰似乎在非堆内存中。具体来说,内存尖峰似乎与Arena Chunk内存空间有关。当比较一个没有经历过尖峰的JVM的内存占用空间时,Thread和Arena Chunk内存空间非常突出。
下面是使用VM内部存储器实用工具对jcmd进行比较。
注意,Arena Chunk内存的数字高得离谱,Thread内存的数字相对较高。
测试的并发级别可以在Tomcat请求线程池中立即创建线程需求。但是,在第一波请求中并不总是会出现尖峰。
,你见过类似的东西吗?你知道是什么导致了尖峰吗?
码头统计
内存Spike容器:
Mon Oct 9 00:31:45 UTC 2017
89440337e936 27.36% 530 MiB / 2.93 GiB 17.67% 15.6 MB / 24.1 MB 122 MB / 2.13 MB 0
Mon Oct 9 00:31:48 UTC 2017
89440337e936 114.13% 2.059 GiB / 2.93 GiB 70.29% 16.3 MB / 25.1 MB 122 MB / 2.13 MB 0普通集装箱:
Mon Oct 9 00:53:41 UTC 2017
725c23df2562 0.08% 533.4 MiB / 2.93 GiB 17.78% 5 MB / 8.15 MB 122 MB / 29.3 MB 0
Mon Oct 9 00:53:44 UTC 2017
725c23df2562 0.07% 533.4 MiB / 2.93 GiB 17.78% 5 MB / 8.15 MB 122 MB / 29.3 MB 0VM内部存储器
内存Spike:
# jcmd 393 VM.native_memory summary
393:
Native Memory Tracking:
Total: reserved=1974870KB, committed=713022KB
- Java Heap (reserved=524288KB, committed=524288KB)
(mmap: reserved=524288KB, committed=524288KB)
- Class (reserved=1096982KB, committed=53466KB)
(classes #8938)
(malloc=1302KB #14768)
(mmap: reserved=1095680KB, committed=52164KB)
- Thread (reserved=8423906KB, committed=8423906KB)
(thread #35)
(stack: reserved=34952KB, committed=34952KB)
(malloc=114KB #175)
(arena=8388840KB #68)
- Code (reserved=255923KB, committed=37591KB)
(malloc=6323KB #8486)
(mmap: reserved=249600KB, committed=31268KB)
- GC (reserved=6321KB, committed=6321KB)
(malloc=4601KB #311)
(mmap: reserved=1720KB, committed=1720KB)
- Compiler (reserved=223KB, committed=223KB)
(malloc=93KB #276)
(arena=131KB #3)
- Internal (reserved=2178KB, committed=2178KB)
(malloc=2146KB #11517)
(mmap: reserved=32KB, committed=32KB)
- Symbol (reserved=13183KB, committed=13183KB)
(malloc=9244KB #85774)
(arena=3940KB #1)
- Native Memory Tracking (reserved=1908KB, committed=1908KB)
(malloc=8KB #95)
(tracking overhead=1900KB)
- Arena Chunk (reserved=18014398501093554KB, committed=18014398501093554KB)
(malloc=18014398501093554KB)
- Unknown (reserved=38388KB, committed=38388KB)
(mmap: reserved=38388KB, committed=38388KB) 正常JVM:
# jcmd 391 VM.native_memory summary
391:
Native Memory Tracking:
Total: reserved=1974001KB, committed=710797KB
- Java Heap (reserved=524288KB, committed=524288KB)
(mmap: reserved=524288KB, committed=524288KB)
- Class (reserved=1096918KB, committed=53738KB)
(classes #9005)
(malloc=1238KB #13654)
(mmap: reserved=1095680KB, committed=52500KB)
- Thread (reserved=35234KB, committed=35234KB)
(thread #35)
(stack: reserved=34952KB, committed=34952KB)
(malloc=114KB #175)
(arena=168KB #68)
- Code (reserved=255261KB, committed=35237KB)
(malloc=5661KB #8190)
(mmap: reserved=249600KB, committed=29576KB)
- GC (reserved=6321KB, committed=6321KB)
(malloc=4601KB #319)
(mmap: reserved=1720KB, committed=1720KB)
- Compiler (reserved=226KB, committed=226KB)
(malloc=96KB #317)
(arena=131KB #3)
- Internal (reserved=2136KB, committed=2136KB)
(malloc=2104KB #11715)
(mmap: reserved=32KB, committed=32KB)
- Symbol (reserved=13160KB, committed=13160KB)
(malloc=9221KB #85798)
(arena=3940KB #1)
- Native Memory Tracking (reserved=1890KB, committed=1890KB)
(malloc=8KB #95)
(tracking overhead=1882KB)
- Arena Chunk (reserved=178KB, committed=178KB)
(malloc=178KB)
- Unknown (reserved=38388KB, committed=38388KB)
(mmap: reserved=38388KB, committed=38388KB) 发布于 2017-10-11 02:57:24
glibc/malloc选项似乎修复了这个MALLOC_PER_THREAD=0。然而,我决定使用debian/openjdk码头底图而不是centos,这也解决了这个问题。
https://stackoverflow.com/questions/46638821
复制相似问题