4

Mavenでjettyサーバーを使用してWebアプリケーションを実行しています。このアプリケーションには、リストとマップに静的オブジェクトの大きなプールが含まれており、2.8GBの物理メモリ使用量に貢献しています。数時間後、サーバーは最大CPU使用率でハングします。これは、サーバー上でユーザーの操作や要求が行われなくても発生します。

この数時間の間に、サーバーが正常に動作している間に、メモリがゆっくりと1.7GBに減少することに気づきました。私の疑いは、これがガベージコレクション関連の問題である可能性があるということです。

質問：

  1. ラージオブジェクトプールとその参照を誤って収集または検査しているときにGCがハングする可能性がありますか？
  2. この問題をデバッグして修正するにはどうすればよいですか？

Windowsではこの問題は発生しないことに注意してください。アプリケーションが起動してプールがいっぱいになると、3.4 GBを占有し、クラッシュすることなくまったく同じ状態を保ちます。

サーバーの起動と環境：

setenforce 0
export MAVEN_OPTS="-Xmx5120m -Xms5120m -XX:+UseConcMarkSweepGC -Xgcthreads1 -XX:MaxGCPauseMillis=2000 -XX:GCTimeRatio=10"
sudo nohup mvn -D jetty.port=80 jetty:run &

オペレーティング·システム：

Ubuntu 12.04.1 LTS

Java：

OpenJDK Runtime Environment (IcedTea6 1.11.5) (6b24-1.11.5-0ubuntu1~12.04.1)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)

Maven： 

Apache Maven 3.0.4

桟橋：

8.1.8.v20121106
4

1 に答える 1

2

システム ハングの原因が GC の誤りによるものかどうかを判断するのは困難です。より多くの情報を得るためにいくつかの動きをすることができると思います：

  1. JVM 引数に追加-verbose:gc -Xloggc:/home/admin/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStampsすると、GC の詳細情報を見つけるのに役立ちます。
  2. スレッド ダンプを定期的に収集して、実行時にアプリケーションで何が起こっているかを確認します。
  3. マシンが停止しようとしているときにメモリ ダンプを取得します。これは MAT で分析できます。
  4. CPU が急上昇した場合、使用top -H -p<pid>してドミネーター スレッドを見つけ、スレッド ダンプでそれらを見つけると、基本的にコードのどの行が間違っているかを見つけることができます。

How to Analyze Java Thread Dumpsの非常に優れた記事を次に示します。

于 2013-01-17T13:46:55.543 に答える