web-dev-qa-db-ja.com

Wildfly 10のメモリリークの問題

Wildfly 10.0.0 Finalバージョンを使用しています。 Java.lang.OutOfMemoryError: GC overhead limit exceeded errorモジュールを9〜10回アンデプロイ/デプロイするときも、wildflyのメモリ使用量は徐々に増加し続け、決して減少せず、再びJava.lang.OutOfMemoryError: GC overhead limit exceeded error.

Wildflyがアプリケーションのアンデプロイ後にメモリを解放せず、デプロイ時に増加し続けるため、GCオーバーヘッドが発生する

以前、wildfly 9バージョンを使用していたときに、その問題は発生しませんでした。

コア、サーブレット、およびWebSocketモジュールを最新のリリースに置き換えることにより、以下のリンクにある修正を試みましたが、うまくいきませんでした。

https://developer.jboss.org/message/959286

この問題の解決方法を誰かに教えてもらえますか？.

javamemory-leaksgarbage-collectionwildfly-10
16
kirti

ヒープメモリを増やす必要があります。このため

bin/standalone.conf構成ファイルを編集し、Java_OPTSの最初の出現を探します。

次に、必要に応じて-Xmxオプションを変更します。

Java 8を使用する場合、

変化する：

Java_OPTS=”-Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true”

に：

Java_OPTS=”-Xms64m -Xmx2G -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=2G -Djava.net.preferIPv4Stack=true”

リソースリンク：

WildFly 10 — Java.lang.OutOfMemoryError：Metadata space

更新： アンデプロイ後にクラスがアンロードされない

Martin koubaは以下に述べています

  1. undeployは、必ずしもクラスのアンロードを意味するわけではありません。これは、JVM設定に依存します（-XX：MaxMetaspaceSizeおよびJava8のフレンド）
  2. 接続された再生装置の50回のデプロイ/アンデプロイサイクルの後（および-XX：MaxMetaspaceSize = 128mを使用）、次のことを確認しました。

wildFly 10.0.0.Finalの「Java.lang.OutOfMemoryError：Metaspace」が発生する

wildFly 10.1.0-SNAPSHOTの場合（ WFLY-6347 マージの修正）OOMエラーは発生しません（メタスペースはガベージコレクションされます）

ヒープダンプを調べた結果、org.jboss.el.cache.BeanPropertiesCacheが根本原因であることがわかりました。この場合、person.joey.test.TestClientBeanクラスへのハード参照を保持するため、関連するModuleClassLoaderをGCから効果的にブロックします。

列挙値は静的定数と同様に扱われます。つまり、所有者クラスのクラスローダーがそうでなければ、ガベージコレクションされません。

そのため、person.joey.test.RequestTypeの値はメモリに残ります。 OmniFacesは影響を増幅するだけです-上記のように、BeanManagerへの参照を保持します。

21
SkyWalker