Java hat kein Speicherproblem mehr

9

Ich habe eine JAR-Datei, die auf einer amazon-ec2-m1.large-Instanz mit einem Linux-64-Bit-Betriebssystem läuft. Ich habe nach verschiedenen Stunden keinen Speicher mehr, normalerweise zwischen 2-4, obwohl ich in meinem letzten Protokoll schreiben (vor der Fehlerdatei erstellt) sehe Folgendes:

%Vor%

Wenn ich vom Start des Jars aus schaue, bis der Speicher voll ist - alle Werte sind gleich und die freeHeapSize liegt zwischen 200-230 MB (ich überprüfe alle 30 Sekunden und mache System.gc ())

in der Datei hs_err_pid2250.log wrriten:

%Vor%

Außerdem verwende ich threadpoolexecutor mit 30 Kernfäden und 100 Max (nie Benutzer mehr als 30, obwohl ich manchmal alle 30 benutze)

Endlich, ich benutze den bonecp-Verbindungspool mit 50 Verbindungen

Irgendwelche Vorschläge? :)

Nach dem Vorschlag habe ich einen Heap-Dump nach dem Ausführen der Anwendung von meinem lokalen PC hinzugefügt. Wie kann ich von hier weitermachen? Sind die kritischen orangen Sprünge wichtig? Oder sind nur die verwendeten wichtig?

    
user502967 06.08.2013, 11:24
quelle

5 Antworten

8

Ich konnte einen fast identischen Fehler beheben, indem ich den folgenden Ratschlägen folgte:

Ссылка

Im Wesentlichen geben sie an:

  

Wenn die Java Virtual Machine startet, erzeugt sie standardmäßig eine Reihe von Garbage Collection (GC) -Threads, die für parallele GC-Operationen verwendet werden ... die Anzahl solcher Threads wird nach folgender Formel berechnet: (ncpus & lt; = 8) ? ncpus: 3 + ((ncpus * 5) / 8) ... Wegen der Erstellung dieser vielen Threads ... wird das Programm automatisch die Systemgrenze erreichen ...

Ich beschränkte die Anzahl der Garbage Collection-Threads mit der Umgebungsvariablen wie folgt:

%Vor%

Ich bin mir nicht sicher über den allgemeinen Leistungseinbruch bezüglich GC, aber zumindest ist die heutige Arbeit erledigt.

Bitte überprüfen Sie den ursprünglichen Post für weitere Optionen.

Viel Glück, - Stu

    
Stu 23.08.2013 17:55
quelle
1

Bitte versuchen Sie die 64-Bit-Version von Java, wenn Sie die 32-Bit-Version verwenden,

Fügen Sie auch das neue JVM-Argument "-XX: + CMSClassUnloadingEnabled \" hinzu, das einige nicht verwendete Klassenobjekte löscht

    
jayalalk 06.08.2013 11:34
quelle
1

Wenn Sie mehr physischen RAM zur Verfügung haben, verwenden Sie das. Es scheint, dass die zugewiesene Heap-Größe nur 1656 mb ist, was vielleicht nicht genug ist. Versuchen Sie, eine Java-Jar-Datei mit zwei Switches -xmx4096mb und -xms 2048 auszuführen Überwachen Sie dann die Verwendung, vielleicht ist der Speicherbedarf zu groß für Ihre Anwendung, wenn Sie nach einiger Zeit immer noch nicht genügend Arbeitsspeicher haben, dann müssen weitere Untersuchungen durchgeführt werden, um zu überprüfen, ob der Code Speicher verliert. Hoffe, das hilft, lass es mich wissen, wenn du mehr Klarheit brauchst.

    
drequinox 06.08.2013 11:48
quelle
0

Heap ist nur ein Teil der Gleichung. Sehen Sie sich den gesamten residenten Speicher an - er enthält Heap- und Off-Heap-Beiträge. Off-Heap enthält gemappte JARs, Thread-Stacks (~ 1MB pro Thread), Perm-Gen, etc. SO hat eine Reihe von Fragen, wie man es unter Linux macht.

    
duffymo 06.08.2013 11:29
quelle
0

Ohne zu versuchen, die Speicherauszugsdaten zu dekodieren, werde ich feststellen, dass es im Grunde drei Fälle gibt, in denen eine JVM nicht genügend Arbeitsspeicher hat:

  1. Mit einer Struktur (Liste von Listen oder whatnot), die Massen ungenutzter (aber immer noch referenzierter) Daten ansammeln darf.
  2. Beliebige "Handles" offen lassen - Dateihandles, Threads, Datenbankoperationen. Vor allem, wenn Sie eine API mit einer nativen Komponente verwenden, können Sie viele Dinge außerhalb der Reichweite von GC lassen.
  3. Erstellen einer einzelnen extrem großen Anfrage (oder eines "Bursts" solcher Anfragen).

Irgendwie dazwischen wären Klassen. Wenn Sie eine App ausführen, die Klassen dynamisch erstellt und lädt, müssen Sie einzelne Klassenladeprogramme ordnungsgemäß verwenden, um die Klassen zu sammeln.

    
Hot Licks 06.08.2013 11:32
quelle

Tags und Links