Ich möchte die volle GC-Frequenz in JMX überwachen. Eine MBean macht die GC-Zählung verfügbar. (cf. http://download.oracle.com/javase/1.5.0/docs/api/java/lang/management/GarbageCollectorMXBean.html - java.lang: type = GarbageCollector, name =).Kann die "Full GC" -Frequenz in JMX (auf HotSpot) überwacht werden?
Das Problem ist, dass MBean nicht zwischen Minor und Full GC unterscheidet.
Hat jemand eine Idee?
Danke.
Arnault
es tut ... werfen Sie einen Blick auf die Namen z. ParNew, ConcurrentMarkSweep, etc. einige Namen sind für kleinere gc, einige für volle gc,
Entschuldigung, aber nicht genau. ParNew und ConcurrentMarkSweep sind GC-Algorithmenimplementierungen und für diese GC können Sie kleinere oder größere Sammlungen verwenden. – ajeanson
Ich bin nicht ganz sicher darüber, aber ich nehme an, dass der Garbage Collector, der alle Speicherpools steuert (zumindest die eine für Old Gen) ist die für große GC. zB: Ich habe eine JVM läuft mit diesen 2 Sammler:
diese Berücksichtigung würde ich sagen, ist PS Scavenge für kleinere gc und PS MarkSweep für großen gc verwendet.
UPDATE (basierend auf @ajeanson Kommentar, vielen Dank für Ihr Feedback btw):
effektiv, das Beispiel, das ich dort legte von den in dem MXBeans der JVM ausgesetzt Informationen genommen wurde war ich mit. Wie Sie bereits erwähnt haben, sind dies GC-Algorithmen, und der Name, den der MXBean für den GC verwendet, basiert auf dem Algorithmus, den der GC verwendet. Ich habe nach mehr Informationen darüber gesucht; in diesem Artikel http://download.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html liest die folgenden:
Die Java HotSpot VM definiert zwei Generationen: Die junge Generation und die alte Generation (manchmal als "Kindergarten" genannt). Die junge Generation besteht aus einem "Eden Space" und zwei "Survivor Spaces". Die VM weist zunächst alle Objekte dem Eden-Space zu und die meisten Objekte sterben dort . Wenn die VM einen untergeordneten GC durchführt, verschiebt alle verbleibenden Objekte aus dem Eden-Raum in einen der Überlebendenbereiche. Die VM verschiebt Objekte , die lange genug in den Überlebenden Leerzeichen auf dem "tenured" Speicherplatz in der alten Generation leben. Wenn die generierte Generation voll ist, gibt es einen vollen GC, der oft viel langsamer ist, weil es alle Live-Objekte betrifft.Die permanente Generation enthält alle reflektierenden Daten der virtuellen Maschine selbst, z. B. Klasse und Methode Objekte.
einen Blick auf die collectionCount Eigenschaft nehmen an den MXBeans im Falle meiner „PS MarkSweep“ Sammler (die die alte Generation Pool verwaltet), scheint die Sammlung Zahl nur zu erhöhen, wenn ich eine vollständige GC erhalten in der ausführlichen Ausgabe. Ich könnte mich irren und vielleicht führt dieser Collector in einigen Fällen auch kleinere GCs durch, aber ich müsste mehr Tests durchführen, um ganz sicher zu sein. Bitte lassen Sie es mich wissen, wenn jemand etwas anderes herausfindet oder Sie genauere Informationen zu diesem Thema haben, da mich das ziemlich interessiert.
Hallo, vielen Dank für Ihren Beitrag, aber IMHO, es sind zwei verschiedene GC-Algorithmen-Implementierungen und für diese GC können Sie kleinere oder größere Sammlungen haben. Ich habe einen Test gemacht, bei dem ich auf verbose GC schaue und ich kann einige "Full GC", aber nur CollectionCount-Incoterationen in meinen MBeans sehen. – ajeanson
können Sie feststellen, dass die alte Gen-Nutzung vor/nach GC nur für volle GC abnimmt. Wenn dies bei Ihnen der Fall ist, reicht dies aus, um vollständige GCs zu identifizieren. – Ron
[Dies könnte Ihnen einen Einblick geben] (https://gist.github.com/khotyn/1520947), welcher GC-Typ auf Ihrer JVM aktiviert ist, wo Sie Ihren Code testen – KJ50