Opzione 1:
Esegui
jstat -gc PID
(con PID sostituito dal PID della JVM per monitorare) che restituirà sth. come:
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
Secondo this di interesse sono:
MC: Metaspace capacity (kB)
MU: Metaspace utilization (kB)
Quindi, in questo caso circa 181mb di Metaspace sono impegnati mentre 137mb vengono utilizzati attualmente.
Opzione 2:
Se si dispone di registri di raccolta della spazzatura abilitati si possono anche trovare questo fuori da lì, per esempio dopo che l'applicazione si è bloccata già o è stato segnalato un problema. Ricerca di linee come
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]
Ciò costituisce un ridimensionamento del Metaspace come è stata raggiunta la soglia precedente.
[Metaspace: 34904K->34904K(1081344K)], 0.1408610 secs]
contiene le informazioni pertinenti: 34,9 MB sono stati utilizzati prima e dopo GC. L'ultima di queste voci di registro che è possibile trovare mostrerà la dimensione corrente (ovvero: dopo GC).
Ricordare che GC completo viene eseguito ogni volta che Metaspace viene ridimensionato. Quindi è una buona idea configurare un buon valore di avvio per questo quando si sa già che il valore predefinito di ~ 21mb (a seconda della configurazione dell'host) non è sufficiente.
Vedere this per ulteriori informazioni sulla regolazione delle dimensioni di Metaspace.
'man jstat' dà le giuste interpretazioni di "MC : Metaspace capacity (kB) "e" MU: Metacspace utilization (kB) ", non" committed "e" used ". – moxn