Почему максимальная память G1 Old gen в jmx равна максимальному размеру кучи?
Я запускаю экземпляр tomcat, включенный с помощью jmx, проверяю статистику памяти G1 старого поколения, нахожу max memory = максимальный размер кучи.
- Окружающая среда
# uname -a
Linux bogon 2.6.32-642.15.1.el6.x86_64 #1 SMP Fri Feb 24 14:31:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
# cat /etc/redhat-release
CentOS release 6.8 (Final)
# java -version
java version "1.8.0_65"
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)
- опция jvm
# ps -ef|grep tomcat
tomcat 3177 1 7 10:23 ? 00:00:06 /usr/java/jdk1.8.0_65//bin/java -Djava.util.logging.config.file=/apps/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -server -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Xms1696m -Xmx1696m -XX:+DisableExplicitGC -XX:MaxGCPauseMillis=200 -XX:+UseStringDeduplication -XX:MetaspaceSize=96m -XX:+UseG1GC -XX:InitiatingHeapOccupancyPercent=45 -XX:MinMetaspaceFreeRatio=50 -XX:MaxMetaspaceFreeRatio=80 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintClassHistogram -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime -Xloggc:/var/log/tomcat/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=2M -XX:+HeapDumpOnOutOfMemoryError -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8415 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.rmi.port=8415 -classpath /usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar -Dcatalina.base=/apps/tomcat -Dcatalina.home=/usr/local/tomcat -Djava.io.tmpdir=/apps/tomcat/temp org.apache.catalina.startup.Bootstrap -Dprocessname=tomcat start
- jmap результат
# jmap -heap 3177
Attaching to process ID 3177, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.65-b01
using thread-local object allocation.
Garbage-First (G1) GC with 1 thread(s)
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 1778384896 (1696.0MB)
NewSize = 1363144 (1.2999954223632812MB)
MaxNewSize = 1066401792 (1017.0MB)
OldSize = 5452592 (5.1999969482421875MB)
NewRatio = 2
SurvivorRatio = 8
MetaspaceSize = 100663296 (96.0MB)
CompressedClassSpaceSize = 1073741824 (1024.0MB)
MaxMetaspaceSize = 17592186044415 MB
G1HeapRegionSize = 1048576 (1.0MB)
Heap Usage:
G1 Heap:
regions = 1696
capacity = 1778384896 (1696.0MB)
used = 84934656 (81.0MB)
free = 1693450240 (1615.0MB)
4.775943396226415% used
G1 Young Generation:
Eden Space:
regions = 81
capacity = 93323264 (89.0MB)
used = 84934656 (81.0MB)
free = 8388608 (8.0MB)
91.01123595505618% used
Survivor Space:
regions = 0
capacity = 0 (0.0MB)
used = 0 (0.0MB)
free = 0 (0.0MB)
0.0% used
G1 Old Generation:
regions = 0
capacity = 1685061632 (1607.0MB)
used = 0 (0.0MB)
free = 1685061632 (1607.0MB)
0.0% used
12869 interned Strings occupying 1777832 bytes.
- Вопрос
Элемент jmx java.lang:type=MemoryPool,name=G1 Old Gen,Usage.max 1778384896, это соответствует максимальному размеру кучи.
Если памяти старого поколения недостаточно, вся память кучи будет использоваться для памяти старого поколения?
0 ответов
Я действительно столкнулся с той же проблемой, что максимальный объем памяти старого поколения такой же, как значение -Xmxв то время как максимальный объем памяти eden и Survivor в интерфейсе JMX равен -1 (неограничен). Спустя всего 5 месяцев после вашего вопроса был выдан билет на выпуск для openjdk "Определения Revamp G1 JMX MemoryPool и GarbageCollector MXBean". Боюсь, мы можем только ждать, пока это будет решено.