So erkennen Sie die Ursache der Fehler wegen ungenügenden Speicherplatzes?

Habe ich eine Beschwerde, dass eine server-Anwendung von mir ist Absturz auf hoher Last.
Es ist eine web-app läuft in Tomcat 5.
Ich sehe der thread-dumps und ich sehe, dass es ein OutOfMemory-Fehler

1TISIGINFO Dump-Ereignis "systhrow" (00040000) Detail
"java/lang/OutOfMemoryError" "Failed to create thread: retVal -1073741830, errno 12" >erhalten 1TIDATETIME Datum: 2012/07/17 20:03:17 1TIFILENAME >Javacore filename:C:\ServerApplication\Tomcat5\bin\javacore.34545719.4646464.4172.0003.txt

Den heap-Informationen ist der folgende:

Maximum Java heap size : 1500m    
Initial Java heap size : 256m

Dies ist die Konfiguration für anfangs-und Max-heap-Größe (32 bit java)

Sehe ich auch, dass es kostenlos verfügbar ist heap space

1STHEAPFREE    Bytes of Heap Space Free: 2D19F3C0   
1STHEAPALLOC   Bytes of Heap Space Allocated: 5DC00000

Dies ist etwa 750 MB freier Speicherplatz, richtig?

Und von der thread-Methode Analyse sehe ich, dass die Anzahl der Threads ist 695 von denen 49% ist java/lang/Object.wait(Native Method) und 39% ist in sun/misc/Unsafe.park(Native Method)
Auch ich sehe das NO JAVA STACK 1% nicht sicher, was das bedeutet.
Auch 0 Laufflächen festgefahren und 2% ist Ausführbar.

Ich bin mir nicht sicher, wie Sie diese Informationen interpretieren oder wie es weiter gehen von hier aus zu erkennen, die zugrunde liegende Ursache.
Jede Hilfe zu diesem?

InformationsquelleAutor der Frage Jim | 2012-07-27

9

Laut dieser Beitrag:
Gibt es zwei mögliche Ursachen für java.lang.OutOfMemoryError:
Fehler beim erstellen eines thread-Nachricht:
- Es gibt zu viele threads ausgeführt werden und das system muss laufen, von den internen Ressourcen, um neue threads erstellen.
- Das system ausgeführt hat native Speicher für den neuen thread. Threads benötigen eine native Speicher für den internen JVM-Strukturen, eine Java™ -
  Stapel, und einen native-stack.
Sodass dieser Fehler kann gut sein, völlig unabhängig von memory, nur, dass zu viele threads erstellt werden...

EDIT:

Als du hast 695 threads, würden Sie brauchen, 695 mal die stack-Größe wie der Arbeitsspeicher. Angesichts dieser Beitrag über thread-Grenzen, ich vermute, dass Sie versuchen, um zu viele threads für den verfügbaren virtuellen Speicher.

InformationsquelleAutor der Antwort beny23
7

Sollten Sie start der JVM mit dem -XX:+HeapDumpOnOutOfMemoryError Flagge. Dies erzeugt einen heap-dump, wenn der OutOfMemoryError generiert.

Dann, wie @Steve sagte, Sie können verwenden Sie ein tool wie MATTE um das Speicherabbild zu analysieren und sehen, welche Objekte zugeordnet sind, und wer hält die Verweise auf Sie. Dies wird in der Regel geben Ihnen einen Einblick, warum Ihre JVM ist anstrengend Speicher.

InformationsquelleAutor der Antwort Flavio
5

Ich weiß, was du meinst, kann es verwirrend sein zu finden, irgendwo zu beginnen.

Haben Sie einen Blick auf Eclipse Memory Analyzer (MAT). Es wird die Verwendung JHat dump ein Speicherabbild des Programms in eine Datei, die Sie öffnen und analysieren.

Browser für diese Datei zeigt alle Objekte, die vom Programm erstellt sehr ordentlich, und Sie können in unterschiedlichen Ebenen zu finden, wenn etwas verdächtig ist.

Anfügen, meine Kommentare zu beantworten...

Recht, wenn Ihr ~~executable~~ webapp stürzt ab, dump es auf MATTE. MATTE wird Ihnen sagen, was für ein Objekt erstellt wird, wird Sie ein paar mal. Wenn es ein benutzerdefiniertes Objekt, und es oft auch ist, es ist leicht zu finden. Wenn nicht, können Sie sehen Ihre Eltern, amputieren, und Dribbeln nach unten, von dort aus (sorry für die Grafik ein Beispiel, ich bin nicht ganz konzentriert auf SO im moment :).

Oh, und ich vergaß zu erwähnen, Sie können führen Sie das Programm mehrmals unter verschiedenen Bedingungen, und machen einen dump jedes mal. Sie können dann analysieren Sie jedes dump für den trend.

Aber in meinem Fall, was soll ich verwenden?Ich habe eine web app läuft im Tomcat

Sorry, verpasst auch diese. Wenn ich mich nicht Irre, MAT gibt die JVM Prozessso lange die VM läuft auf der box sichern Sie Ihre Prozesse und sehen, was Los ist.

Anderen Kommentar mutiert die partielle Lösung...

Dies ist schwieriger, als es tatsächlich ist. Im ernst, es ist ziemlich einfach, nach der Ausführung MAT, einmal oder zweimal,, um den Dreh raus zu bekommen. Führen Sie Ihre app, bis das Ding stürzt ab. Dump es. Ändern Sie etwas. Laufen, crash dump. Wiederholen Sie. Dann öffnen Sie die dumps in der MATTE, und vergleichen, was verdächtig erscheint.

Der schwierigste Teil, wenn ich lernen mußte, das war das finden der Prozess-ID dump - das ist immer noch nicht zu Verstand-numbing.

InformationsquelleAutor der Antwort Ben
2

Eine ähnliche Meldung auf IBM WebSphere zeigt diese Zeile

"Fehler beim erstellen eines thread: retVal"

als Indikator für eine native OOMdas heißt, ein thread (der Prozess) wird versucht, auf Anfrage einem großen Angebot von Speicher auf dem heap.

Den IBM link oben hat eine Reihe von Schritten, von denen einige IBM-spezifische. Einen Blick zu haben.

Von einem native memory-Nutzung-Perspektive:
- Maximale Java-heap-Einstellungen
- JDBC-Treiber
- JNI-code oder Systemeigenen Bibliotheken
- garbage collection von nicht verwendeten Klassen. Ensurethat -Xnoclassgc ist nicht festgelegt.
- Thread-Pool-Einstellungen (Feste Größe thread-pools)
- Zu viele classloadern, etc, aber diese sind nicht sehr Häufig.
- Anzahl der Klassen/classloadern von javacores.
Andere Sache, die Sie betrachten könnte, ist die PermGenSpace - wie groß ist es?

Diesen link http://www.codingthearchitecture.com/2008/01/14/jvm_lies_the_outofmemory_myth.html schlägt

Erhöhung der heap-Allokation tatsächlich verschärft dieses problem!!! Es
sinkt der Spielraum, den der compiler und andere native Komponenten
um mit zu spielen. Also die Lösung zu meinem problem war:
1.reduzieren heap zugeordnet die JVM.
2. entfernen Sie die Speicher-Lecks, verursacht durch native Objekte nicht freigegeben wird, in eine rechtzeitige fashion.

Haben auch Sie konfiguriert einen Wert in server.xml für maxThreads ? Der Standardwert ist 200, aber Ihre app zu haben scheint 695 ?

InformationsquelleAutor der Antwort JoseK

Fix

Folgte die IBM technote java.lang.OutOfMemoryError beim erstellen neuer threadsinsbesondere 'ulimit' - Befehl, um den Wert aus der Standard-1024.

Symptom

[2/25/15 12:47:34:629 EST] 00000049 SystemErr     R java.lang.OutOfMemoryError: Failed to create a thread: retVal -1073741830, errno 11
[2/25/15 12:47:34:630 EST] 00000049 SystemErr     R     at java.lang.Thread.startImpl(Native Method)
[2/25/15 12:47:34:630 EST] 00000049 SystemErr     R     at java.lang.Thread.start(Thread.java:936)
[2/25/15 12:47:34:630 EST] 00000049 SystemErr     R     at org.eclipse.osgi.framework.internal.core.InternalSystemBundle.stop(InternalSystemBundle.java:251)
[2/25/15 12:47:34:630 EST] 00000049 SystemErr     R     at com.ibm.ws.runtime.component.RuntimeBundleActivator.shutdownEclipse(RuntimeBundleActivator.java:54)
[2/25/15 12:47:34:630 EST] 00000049 SystemErr     R     at com.ibm.ws.runtime.component.ServerCollaborator$ShutdownHook$1.run(ServerCollaborator.java:878)
[2/25/15 12:47:34:630 EST] 00000049 SystemErr     R     at com.ibm.ws.security.auth.ContextManagerImpl.runAs(ContextManagerImpl.java:5459)
[2/25/15 12:47:34:631 EST] 00000049 SystemErr     R     at com.ibm.ws.security.auth.ContextManagerImpl.runAsSystem(ContextManagerImpl.java:5585)
[2/25/15 12:47:34:631 EST] 00000049 SystemErr     R     at com.ibm.ws.runtime.component.ServerCollaborator$ShutdownHook.run(ServerCollaborator.java:850)
[2/25/15 12:47:34:631 EST] 00000049 SystemErr     R     at com.ibm.ws.runtime.component.ServerCollaborator$StopAction.alarm(ServerCollaborator.java:809)
[2/25/15 12:47:34:631 EST] 00000049 SystemErr     R     at com.ibm.ejs.util.am._Alarm.run(_Alarm.java:133)
[2/25/15 12:47:34:631 EST] 00000049 SystemErr     R     at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1815)

Umgebung

CentOS 6.6 64 bit
IBM WAR 8.5.0.2 64 bit

Referenzen

Richtlinien für die Einstellung, die ulimits (WebSphere Application Server)

InformationsquelleAutor der Antwort mon

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.