Ich brauche Hilfe, um zu verstehen, wie sich die GC-bezogenen Zahlen, die ich von jmap und jstat erhalte, auf die Einstellungen beziehen, die ich an Java übergebe. Ich starte die App (solr) mit den folgenden Einstellungen auf einem Server mit 16 GB Speicher:
Die Ausgabe von jmap beginnt:
Warum sind NewSize , MaxNewSize , OldSize und PermSize alle so klein, wenn MaxHeapSize groß ist? Sollte nicht NewSize + OldSize = heap size ? Und sollte sich die Gesamtgröße des Heapspeichers nicht% MaxHeapSize nähern? Warum ist NewSize genau die Hälfte von OldSize , wenn NewRatio auf 4 gesetzt ist?
Der Rest der jmap -Ausgabe ist darunter. Es entspricht dem obigen und enthält einen Abschnitt concurrent mark-sweep generation , den ich auch nicht interpretieren kann.
Zusätzlich zeigen die GC-Logs an, dass die "erwünschte Überlebendengröße" 6,2 MB beträgt, was auch seltsam ist, wenn ich weiß, dass -XX:SurvivorRatio=8 den Überlebendenraum 1/8 von NewSize machen sollte.
Schließlich sehe ich in meinem GC-Log immer nur ParNew messages, was ich unter GC für Eden verstehe.
Warum sind NewSize, MaxNewSize, OldSize und PermSize alle so klein, wenn die MaxHeapSize groß ist?
Die Größen sind nur so groß, wie sie sein müssen. Die NewSize wird größer sein, wenn Sie mehr kurzlebige Müll erzeugen (ich weiß nicht, wie die MaxNewSize festgelegt ist, aber es ist in der Regel kleiner als was ich festlegte)
gleichzeitige Mark-Sweep-Generierung
Dies hat die capacity = maximale Größe, used = verwendet, free = Kapazität - verwendet.
ParNew-Nachrichten in meinem GC-Protokoll, die ich verstehe, ist der GC für Eden.
Wie Sie bemerkt haben, ist der neue Raum klein, so dass er oft aufräumt und das alte Gen groß ist, so dass es, wenn überhaupt, nur selten aufräumt.
Tags und Links java garbage-collection solr