2

Java サーバーが繰り返しクラッシュし始めましたが、その理由がわかりません。

7.5GB のメモリを搭載したサーバーがあり、Java プロセスに 3GB を割り当てました。

サーバーは正常に動作しており、ガベージ コレクションを何度も実行していましたが、JVM はメモリ不足でクラッシュしました。

クラッシュ後の JConsole からの情報は次のとおりです。

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 kbytes

私は GC の実行後に 0.5 GB を持っているので、常に 0.5 から 3 GB に上昇し、その後 0.5 にフォールバックしますが、ぶら下がっているオブジェクトにはまったく問題はありません。実際OutOfMemoryException、クラッシュするのではなく、スローする必要があります。私はこれらのパラメータを使用しています:

-Xmn256m -Xms768m -Xmx3000m -XX:NewRatio=2 -server -verbosegc -XX:PermSize=256m -XX:MaxPermSize=256m -XX:SurvivorRatio=8 -XX:+UseParallelGC -XX:ParallelGCThreads=2 -XX:+UseParallelOldGC

何が問題で、どうすればよいですか? 表示された出力は次のとおりです。

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
...
4

4 に答える 4

1

リンクしたクラッシュ ドキュメントから、エラーは SIGSEGV であり、これはネイティブ メモリへの読み取り/書き込みエラーです。スレッド スタックは、JVM コードでクラッシュしたことを示しています。

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
<snip>

JVM のバグか、メモリの破損である可能性があります。

于 2011-02-15T13:51:37.847 に答える
0

メモリリークのように聞こえます。GC は、参照されなくなったオブジェクトのみをクリーンアップできます。また、アプリケーション (またはサーバー自体) が未使用のリソースを「解放」しない場合、しばらくすると 3GB でも十分ではなくなります。

プロファイラーは、予想外に大きくなるデータ構造を特定するのに役立つ場合があります。

アイデア:-verbose:gcオプションでサーバーを起動し、停止する直前に何が起こるかを確認します。長時間待機する必要がないように、テストのヒープ領域を減らします。メモリ リークの場合は、GC が実行されるたびに解放されるメモリが少なくなる定期的な完全な GC サイクルが見られると思います。

アップデート

outofmemoryerrorタグに騙されました。実際、これは JVM のクラッシュであり、インストールされている Java を更新しようとすることしかできません。ビルド 1.6.0_17 および 1.6.0_18 の「SIGSEGV (0xb)」クラッシュに関するレポートが既にいくつかあります ( SO に関するこの質問のように)。

これは JVM 内部の問題です。

于 2011-02-15T12:34:25.313 に答える
0

「メモリの問題」があり、物理ハードウェアに欠陥があるのではないかと心配している場合は、ストレス テストを強く検討する必要があります。

従来の PC でこれを行う通常の方法は、memtest86 を使用することです。最新バージョンは、 http ://www.memtest.org/ から入手できるようです。

メモリが memtest86 による一晩中のテストに合格した場合、メモリが正しく動作することはほぼ確実です。

于 2011-02-15T12:45:11.217 に答える
0

JVM に 3 GB を割り当てたと言う場合、これはヒープ サイズまたは合計サイズ (かなり大きくなる可能性があります) でしたか。たとえば、3 GB ヒープの JVM は clsoe を合計 4 GB まで使用できます。

JVM が GC でクラッシュした場合は、Java 6 update 23 などの最新バージョンの JVM があることを確認します。

クラッシュは何でしたか？同じクラッシュが他の人から報告されている場合があり、Google で検索できます。場合によっては、推奨される解決策があります。

于 2011-02-15T12:56:40.080 に答える