私はOpen SDK 1.7.0_95 64ビン環境で動作するJavaアプリケーションを持っています。毎回2つの主要なガベージコレクションがあり、アプリケーションの応答時間がピークに達しています。現在、あなたのキットのプロファイルを使用してアプリケーションをプロファイリングしています。可能であれば、これらの主要なGCの原因をトラブルシューティングして回避するための手順を教えてください。アプリケーションは、Linux環境でJboss EAP 6.2にデプロイされます。大きなガベージコレクションの原因のトラブルシューティング
OpenJDKのランタイム環境（RHEL-2.6.4.0.el6_7-x86_64のU95-B00） OpenJDKの64ビットサーバーVM（24.95-B01、混合モードを構築する）
何か他のものから必要な場合は私に知らせてください私の側。 ありがとうございます！ よろしく、 Divya Garg
「私の車は何が起こっているのかを知るためには何がすべきか」という質問があります。その答えは - 有資格の自動車修理サービスに相談してください。 -XX:+PrintGC上
電源を入れhappenning何の詳細を参照する：あなたが試すことができますどのような
。
メジャーGCは1時間に1回程度の頻度でアプリケーションを停止しますが、GCの設定が悪いことを示唆しています。通常、メモリの大量のメモリが与えられている貪欲なアプリケーションで発生します。その後、GCが数ギガバイトをクリーンアップしなければならず、処理が数分停止することがあります。 parallel collectorをチェックするか、または一般的に "ガベージコレクションチューニング"を独自の技術です。
メモリリークの問題があるかもしれませんが、そうでないかもしれません。プロファイリングも独自の技術です。最大の配分を探し、どこから来たのかを調べて、なぜそれらがまだ参照されていて、クリーンアップできないのか調べてみてください。
私は現在、Open SDK 1.7.0_95 64を使用しているJVMは、並列コレクタを使用してalredayです。私の分析によれば、葬儀の漏れの問題はありません。私は、VM引数surviverRatioを減らして試しています。それは、大きなGC頻度を減らすのに貢献できるように見えます。ありがとう –
あなたの設定が何であるかについての詳細を投稿することができます。あなたのヒープの大きさ、使用しているコマンドラインオプションなどこれがなければ、プロファイリングデータがなくてもこれは疑問のない質問です。古い世代の長い休止は、通常、完全な圧縮を実行するGCの必要性に左右されます。これは、GCが割り振りの速度やヒープの過度の断片化に追いつくことができないことの結果です。まず、ヒープのサイズを増やしてみてください。他にも多くの情報がありますが、それ以上の情報がなければ、あまり意味はありません。 – Speakjava
-XX：+ UseCompressedOops -XX：+ TieredCompilation -Xmx1978m -XX：MaxPermSizeを= 256メートル -XX：+ AggressiveOpts -DOPENSHIFT_APP_UUID = 59c0cc814930e9981c000923 -Dorg.jboss.resolver.warning =真 -Djava.net。 preferIPv4Stack =真 の-Dfile.encoding = UTF-8 -Djava.net.preferIPv4Stack = trueを -Djboss.node.name = 9d6nra5nfc4-9d6nra5nfc4.dmp-dev.ficoanalyticcloud.com -Djgroups.bind_addr = 127.107.196.129 -Dorg.apache.coyote.http11.Http11Protocol.COMPRESSION = on -Dhttps.protocols = TLSv1.1、TLSv1.1、TLSv1.2 –
こんにちは、現在、私は偽のサービスを単一のJVMでテストしています3GBのメモリを搭載し、ヒープスペースを1978MBから3GBに拡大しようとしました。そこでは、主要なGC周波数が1時間に2回から1.6時間に1回に変わりましたが、私はそれを完全に取り除こうとしています。出来ますか ？マイナーGCで収集されず、古いGCに昇格したクラスをいくつか見つけました。具体的に私がこれらのクラスを分析したり、これを進めるために正しい方向を示していることをお勧めしますか？ –