Java ist abgestürzt, Anwendung - so finden Sie heraus, warum Java abgestürzt?
Meine java-server gestartet-Absturz wiederholt, und ich kann nicht herausfinden, warum.
Ich habe server mit 7,5 GB Speicher und ich habe reserviert 3GB für den java-Prozess.
Server war einwandfrei läuft und lief garbage collection viele Male, aber die JVM-Crash bei unter Speicherdruck.
Hier die info von JConsole, nach dem Absturz:
Current heap size:
2 958 868 kbytes
Maximum heap size:
3 066 816 kbytes
Committed memory:
3 066 816 kbytes
Pending finalization:
0 objects
Garbage collector:
Name = 'PS MarkSweep', Collections = 66, Total time spent = 7 minutes
Garbage collector:
Name = 'PS Scavenge', Collections = 43 055, Total time spent = 44 minutes
Operating System:
Linux 2.6.31-302-ec2
Architecture:
amd64
Number of processors:
2
Committed virtual memory:
8 405 760 kbytes
Total physical memory:
7 882 780 kbytes
Free physical memory:
34 540 kbytes
Total swap space:
0 kbytes
Free swap space:
0 kbytesHabe ich 0,5 GB nach einem GC-Lauf, so dass alle die Zeit, die er aufwirft, von 0,5 bis 3 GB und als fall-back 0,5, ist es absolut kein problem mit hängenden Objekte. In der Tat sollte es werfen OutOfMemoryException statt abzustürzen. Ich bin mit diesen Parametern:
-Xmn256m -Xms768m -Xmx3000m -XX:NewRatio=2 -server -verbosegc -XX:PermSize=256m -XX:MaxPermSize=256m -XX:SurvivorRatio=8 -XX:+UseParallelGC -XX:ParallelGCThreads=2 -XX:+UseParallelOldGCWas ist falsch und was soll ich tun? Die gezeigte Ausgabe war:
Current thread (0x00007fe899755800): JavaThread "508616253@qtp-1871151428-3352" [_thread_in_vm, id=11941, stack(0x00007fe86a4e5000,0x00007fe86a5e6000)]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=128 (), si_addr=0x0000000000000000
Registers:
RAX=0x00007fe9c60333b8, RBX=0x00007fe899755800, RCX=0x0d00007fe8f58787, RDX=0x00007fe9c6031888
RSP=0x00007fe86a5e3fd0, RBP=0x00007fe86a5e4020, RSI=0x00007fe899755800, RDI=0x00007fe95bae1770
R8 =0x00007fe9be341620, R9 =0x0000000000000001, R10=0x00007fe9c5b84460, R11=0x00007fe9c051a52b
R12=0x00007fe9c051a529, R13=0x00007fe9c6034ac0, R14=0x00007fe9c051a599, R15=0x0900007fe8f58787
RIP=0x00007fe9c5bd562d, EFL=0x0000000000010246, CSGSFS=0x000000000000e033, ERR=0x0000000000000000
TRAPNO=0x000000000000000d
Stack: [0x00007fe86a4e5000,0x00007fe86a5e6000], sp=0x00007fe86a5e3fd0, free space=3fb0000000000000030k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x64d62d]
V [libjvm.so+0x5fc4df]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v ~RuntimeStub::_complete_monitor_locking_Java
J sun.nio.ch.SocketChannelImpl.write(Ljava/nio/ByteBuffer;)I
J org.mortbay.io.nio.ChannelEndPoint.flush(Lorg/mortbay/io/Buffer;)I
J org.mortbay.jetty.HttpGenerator.flush()J
...die Tatsache, dass du bist 'tun' GC viele Male sollten von alarm-Glocken. was ist der server Verhalten, wenn Sie nicht tun, keine GC und verlassen Sie sich auf die JVM zu führen, wie es sieht am besten?
Welche Programme ausgeführt werden? Java führt die garbage collection durch sich selbst, aber wenn ein Programm verursacht einen Speicherverlust dies kann nicht genug sein.
Nein, es ist kein JNI verwendet.
Server ist auf heavy load, houndrets der angeschlossenen online-Nutzer, die oft die garbage-collection-Aufrufe sind schnelle garbage-collection-algorithmen konfiguriert von mir, die helfen, zu verhindern, dass Zeit-Lecks, während Sie regelmäßige GB colection.
InformationsquelleAutor Libor Havlicek | 2011-02-15
Du musst angemeldet sein, um einen Kommentar abzugeben.
Aus der crash-doc verlinkt, der Fehler ist ein SIGSEGV, das ist ein Fehler beim Lesen/schreiben von nativen Speicher. Der thread-stack zeigt es stürzte in JVM-code.
Könnte ein JVM-Fehler, oder vielleicht Speicher Korruption.
InformationsquelleAutor Mike Tunnicliffe
Wenn du mit "Speicher-problem" meinst, dass Sie besorgt sind, dass Ihre physischen hardware defekt ist, sollten Sie dringend in Erwägung ziehen, stress zu testen.
Für traditionelle PC ist der übliche Weg, dies zu tun ist mit memtest86. Die neueste version scheint verfügbar zu sein von hier: http://www.memtest.org/
Wenn die memory-pass ein all-night-test mit memtest86 kannst du ziemlich sicher sein, es richtig funktioniert.
Gut, dann ist das geklärt. Schauen Sie in jvisualvm im JDK - es ermöglicht Ihnen, die profile eines Laufenden Programms - Sie brauchen, um Speicherverluste zu suchen.
InformationsquelleAutor Thorbjørn Ravn Andersen
Wenn Sie sagen, dass Sie reserviert 3 GB für die JVM, war dies die heap-Größe oder die Gesamtgröße (das kann durchaus ein bisschen größer), z.B. eine JVM mit einem 3 GB heap verwenden konnte, empfängt bis zu 4 GB insgesamt.
Wenn die JVM hat stürzte auf einen Tisch, ich würde prüfen, ob Sie eine aktuelle version der JVM, wie Java 6 update 23.
Was war der Absturz? Manchmal ist der gleiche Absturz wird berichtet von anderen Menschen, und Sie können google es. Manchmal gibt es einen Lösungsvorschlag.
Und auch früher habe ich JAVA 5, JAVA 6-neueste, OpenJDK neueste, immer das gleiche Ergebnis. Und JVM generiert hat, crash-Dateien, nicht immer, aber manchmal ja. Finden Sie Beispiel von crash-Datei hier: chessfriends-release.s3.amazonaws.com/logs/...
Ich fand Java 6 update 18 stabil zu sein. Aber dennoch einen Versuch Wert update 23 oder 24, bei dem mit einem viel neueren JVM. (mehr als ein Jahr AFAIK)
Ich verwendet 6.23 auch, Gleiches Ergebnis.
Das einzige, einfache Sache, die ich vorschlagen kann, ist versuchen, die 32-bit-version (obwohl dies möglicherweise nicht genug Speicher haben) Es sieht aus wie ein JVM/native bug zu mir. Die nächste Sache, die Sie tun können, ist versuchen, Ubuntu 10.x 😐
InformationsquelleAutor Peter Lawrey
Klingt wie ein memory leak. Der gc kann nur Objekte bereinigen, die nicht mehr referenziert. Und, falls Ihre Anwendung (oder der server selbst) nicht "frei" ungenutzte Ressourcen, nach einer Weile, selbst 3GB sind nicht genug.
Profiler helfen könnte, zu identifizieren Datenstrukturen, die wachsen unerwartet.
Idee: starten Sie den server mit
-verbose:gcoption und prüfen Sie, was passiert, kurz bevor es stirbt. Sinken heap-Speicher für den test, so dass Sie nicht haben, zu warten, zu lange. Wenn es ein memory leak erwarte ich, dass Sie sehen, regelmäßige vollständigen gc-Zyklus, wo der gc kann kostenlos weniger Speicher jedes mal, wenn es läuft.Update
War ich irrezuführen, indem der
outofmemoryerrortag. In der Tat, es ist eine JVM-Absturz, und alle, die Sie tun können, ist zu versuchen, ein update der installierten Java. Es gibt bereits einige Berichte über "SIGSEGV (0xb)" Abstürze baut 1.6.0_17 und 1.6.0_18 (wie diese Frage auf SO).Es ist eine JVM-internen problem.
Nein, es ist Müll gereinigt werden. Ich habe die ganze Zeit 0,5 gb nach GB laufen, so dass alle die Zeit, die er aufwirft, von 0,5 bis zu 3 GB und dann wieder fallen zu 0,5, es ist absolut kein problem mit hängenden Objekte. In der Tat ist es suould werfen OutOfMemoryException anstelle von crash-und keine Ausnahme. Ich bin mit diesen params: -Xmn256m -Xms768m -Xmx3000m -XX:NewRatio=2 -server -verbosegc -XX:PermSize=256m -XX:MaxPermSize=256m -XX:SurvivorRatio=8 -XX:+UseParallelGC -XX:ParallelGCThreads=2 -XX:+UseParallelOldGC
Ich werde dringend davon abgeraten, mit dem basteln für die JVM-Parameter, bis Sie eine zuverlässige Konfiguration zu arbeiten! Auch diese information ist so wichtig, dass es gehen sollte, die in Ihrer Frage.
ok, ich habe es in der Frage.
InformationsquelleAutor Andreas_D