Ответ 1
Вариант 1:
Выполнить
jstat -gc PID
(с заменой PID на PID JVM для мониторинга), который вернет sth. как:
S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT
103936.0 107008.0 0.0 41618.3 820736.0 401794.3 444928.0 183545.7 181888.0 137262.8 28544.0 20386.6 313 16.024 8 3.706 19.729
В соответствии с этот представляет интерес:
MC: Metaspace capacity (kB)
MU: Metaspace utilization (kB)
Таким образом, в этом случае около 181mb Metaspace фиксируются, а в настоящее время используется 137mb.
Вариант 2:
Если у вас есть журналы сбора мусора, вы также можете найти это оттуда, например. после того, как приложение потерпело крах или сообщила о проблеме. Найдите строки типа
2016-04-06T01:50:04.842+0200: 7.795: [Full GC (Metadata GC Threshold)
[PSYoungGen: 7139K->0K(177152K)]
[ParOldGen: 18396K->22213K(101888K)] 25535K->22213K(279040K),
[Metaspace: 34904K->34904K(1081344K)], 0.1408610 secs]
[Times: user=0.45 sys=0.00, real=0.14 secs]
Это представляет собой изменение размера метапроцесса при достижении предыдущего порога.
[Metaspace: 34904K->34904K(1081344K)], 0.1408610 secs]
содержит соответствующую информацию: 34,9mb использовались до, а также после GC. Последняя из этих записей журнала, которую вы можете найти, покажет текущий размер (то есть: после GC).
Имейте в виду, что полный GC запускается всякий раз, когда Metaspace изменяется. Поэтому неплохо настроить хорошее начальное значение для этого, когда вы уже знаете, что значение по умолчанию ~ 21mb (в зависимости от конфигурации хоста) недостаточно.
Подробнее о настройке размера метаданных см. .