0

何が間違っているかを理解する方法に関する解決策またはヒントを探しています。

参照が保持されていることを示す VisualVM ツールでヒープダンプを見る。使用できるより良いツールはありますか? これらの参照を解放するためにコマンド ラインから実行できるものはありますか? jconsole GC を使用しても機能せず、約 5 日間ロックアップが長引くだけです。

Linux サーバーは、10 ~ 14 日ごとに次の Java OOM を取得します。

Apr 18, 2012 1:34:55 PM org.apache.jk.core.MsgContext action
WARNING: Error sending end packet
java.net.SocketException: Broken pipe
    at java.net.SocketOutputStream.socketWrite0(Native Method)
    at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
    at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
    at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:508)
    at org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:112)
    at org.apache.jk.core.MsgContext.action(MsgContext.java:293)
    at org.apache.coyote.Response.action(Response.java:182)
    at org.apache.coyote.Response.finish(Response.java:304)
    at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:204)
    at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
    at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:744)
    at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:674)
    at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:866)
    at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
    at java.lang.Thread.run(Thread.java:636)
Apr 18, 2012 1:34:55 PM org.apache.jk.common.ChannelSocket processConnection
WARNING: processCallbacks status 2
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid20051.hprof ...
Heap dump file created [1147163590 bytes in 149.230 secs]
Apr 18, 2012 1:59:14 PM ServerCommunicatorAdmin reqIncoming
WARNING: The server has decided to close this client connection.
Apr 18, 2012 1:59:14 PM ServerCommunicatorAdmin reqIncoming
WARNING: The server has decided to close this client connection.
4

2 に答える 2

0

クラッターの遅い蓄積を修正しても VM の微調整を考えるのに本当に役立たない場合は、VM args (実行java -X) を見てください。たぶん、これらのいくつかはあなたにとって興味深いものです (ただし、OOM 例外なしで時間を延長するだけかもしれません):

-Xms 初期 Java ヒープ サイズ
を設定 -Xmx 最大 Java ヒープ サイズ
を設定 -Xss Java スレッド スタック サイズを設定
-Xprof 出力 CPU プロファイリング データ

于 2012-04-25T17:50:36.623 に答える
0

-Xmx を使用して最大ヒープ サイズを設定し、-Xss を使用してスレッド スタック サイズを設定します。覚えておくべき重要なことは、多数のスレッドを作成する場合は、可能な限り小さいスタック サイズを設定して、使用できるスレッドの数を最大にする必要があるということです (スレッドを作成しようとすると OOM エラーが発生し、スタックに十分なスペースがありません)。また、ヒープが大きいほど、スレッド スタック用のスペースが少なくなります。したがって、ヒープとスタックの間の最適な分割を得るには、おそらく少し実験する必要があります。

私は、ヒープに256M、スレッドあたり64K(-Xmx256m -Xss64k)の1Gbのメモリ(数年前ですが、まだ非常にうまく機能している)を備えたLinuxサーバーを使用して、非常にうまく管理しました。また、わかりやすい名前の -XX:+HeapDumpOnOutOfMemoryError フラグを試し、JMX を使用して .hprof ダンプを取得し、Eclipse メモリ アナライザーで分析して、メモリ リークがないかどうかを確認する必要があります。

于 2013-11-25T17:13:24.450 に答える