ワーキングコンピューターのオペレーティングシステムをWin7に置き換えた後、私のMyeclipseはスタートアップとランニング速度で不十分でした。特に、複数のページテンプレートを同時に変更およびデバッグする場合、2つのファイル間の切り替えは常に約10秒間貼り付けられます。さまざまなプラグインをオフにして確認しようとすると、それらが役に立ちません。そのため、JVMを大まかに研究した後、私はJVMの観点からこの問題を解決しようとすることにしました。
最適化を開始：
まず、myeclipse.iniのデフォルトの起動パラメーターを見てみましょう。
-XMX512M：最大ヒープメモリ値を512mに設定します
-xx：maxpermsize = 256m：永続的な世代の最大値を256mに設定します
-XX：ReservedCodeCachesize = 64M：コードで占有されているメモリサイズを64mに設定します
スタートアップパラメーターからは何も見ることができないため、メモリの変更に関連するパラメーターを追加します。
-xx：+printgctimestamps：各GCのタイムスタンプを印刷します
-xx：+printgcdetails：各GCの詳細情報を印刷します
-xloggc：myeclipsegc.log：ファイルにGCレコードを出力します
-verbose：gc：各GCの関連する状況を出力します
次に、myeclipseを起動し、myeclipsegc.logで情報を確認します。
スタートアップには約30秒かかります。ログのごく一部を選択的に傍受します。 Myeclipseの起動の最初の10秒で、JVMが300 GCと9つのフルGCを実行したことがわかります。
GCの頻度と情報から、メモリの回復速度が非常に高く、サイズが常に調整されていることがわかります。これは、若い世代のスペースが不十分であるためであり、かなりの初期値が必要です。
次に、完全なGCに焦点を当てます。
次のようにコードをコピーします：5.961：[完全なGC 5.961：[テニュード：34568K-> 34456K（49676K）、0.1397651秒] 35336K-> 34456K（53452K）、[PERM：26623K-> 26458K（26624K）、0.1398K] [時間：user = 0.14 sys = 0.00、real = 0.14秒]
9.030：[フルGC 9.030：[テニュード：53310K-> 523332K（64588K）、0.2034757秒] 56020K-> 52332K（69516K）、 sys = 0.00、real = 0.20秒]
2つのログの比較から、完全なGCが主に在職期間とPermの2つの領域をリサイクルしていることがわかります。これらの2つの領域のサイズは常に調整されているため、最初にサイズを修正することにしました。
したがって、調整されたパラメーターは次のとおりです。
-xms512m：スタックの最小値を512mに設定します
-xmn192m：若い世代のサイズを192mに設定します
-xx：permsize = 192m：永続的な生成の初期値を192mに設定します
-xx：maxpermsize = 192m
-XX：ReservedCodeCachesize = 64M
-xx：+printgctimestamps
-xx：+printgcdetails
-xloggc：myeclipsegc.log
-verbose：gc
ログ情報を表示するには、1回のMyEclipseを再起動します。
スタートアップには約12秒かかりました。ログから、最初の10秒で5 GCのみが実行され、各エリアのサイズを調整しなかったことがわかります。この結果は、作業中に頻繁に再起動する必要がないため、受け入れられます。
作業応答速度の最適化：
次に、HTMLファイルを前後に切り替える際に、長い間私を悩ませていた頻繁な遅延と大きなカードの問題を研究しました。 JVMのメモリの変更をより直感的に研究するために、Javaに付属するヘルパーツールであるJConsoleを使用することにしました。最初にmyeclipse.iniのパラメーターを復元して、最適化の最初の段階からの干渉を避けます。
myeclipseを起動し、JConsoleを開始し、MyeclipseがあるJVMに接続します。 stable舎の後のヒープ全体の記憶図は次のとおりです。
次に、いくつかのテンプレートを開いてから、メモリの変更を観察してみてください。
まず、ヒープメモリの全体的な使用法：
いくつかのテンプレートを開いた後、ヒープメモリの使用が100m未満のオリジナルから300m以上に突然増加したことがわかります。使用法は3倍になりましたが、設定した512mの範囲内にあります。したがって、一時的にヒープメモリの増加を継続することを検討することはできませんが、代わりに各ゾーンのメモリサイズ比を調整することを検討することができます。
したがって、この期間中に各ゾーンのメモリの使用が観察されます。その中で、エデンゾーンは次のとおりです。
この期間中、エデンエリアのメモリ使用率は大幅に増加し、GCは数回発生しました。以下の監視情報を通じて、デフォルトでは、エデン領域が31mの最大メモリのみを割り当てるだけではありませんが、これだけでは不十分であることがわかります。小さなポイントを実行すると、EdenエリアのGCがトリガーされます。これは、テンプレートの開くスイッチで遅延遅延の理由の1つであり、調整する必要があります。
次は終身領域です：
JVMによってこのエリアに割り当てられた最大スペースは、デフォルトで470mです。メモリの使用量が変化すると、この領域の実際のサイズは常に調整されています。エリアサイズが調整されるたびに完全なGCが発生します。これは、頻繁に大きなブロックの理由の1つであるはずです。新しいテンプレートの開くことは、この調整をトリガーする主な理由です。この領域のメモリ使用の観点からは、この領域のメモリスペースを約450mで維持および固定することにより、一定量の冗長性を維持する必要があります。
この観点から、JVMのヒープメモリを拡張して、より大きな終身領域とエデンエリアを維持することが依然として必要です。
最後に、Perm領域を見てみましょう。
メソッド領域の一部として、この領域のメモリの変化は大きくなく、比較的安定していないため、あまりにも多くの冗長性を残す必要はありません。ただし、現在開かれているプロジェクトの実際のコードボリュームが大きくないことを考慮すると、一時的に128mに維持し、将来ゆっくりと調整することが決定されます。
したがって、上記の分析によると、パラメーターは次のように調整されます。
-xmx768m
-xms768m
-xmn256m
-xx：permsize = 192m
-xx：maxpermsize = 192m
-XX：ReservedCodeCachesize = 64M
MyEclipseを再起動し、JConsoleに接続し、同時にテストを行うために30テンプレートを開きます。各ゾーンのメモリ使用率を見ると、問題が発見されました。若い世代を256mに調整した後、EdenはGCで頻繁に発生しなくなったため、終身在庫に入るデータの量は大幅に減少します。終身領域のメモリ使用図は次のとおりです。
上の図に示すように、多くのテンプレートが意図的に開かれている場合、450m+スペースは250m未満しか使用しておらず、スペース使用率が低すぎるため、調整を行う必要があります。
要約します
上記は、私が自分の乳首を調整するためのいくつかのアイデアと実際のチューニングプロセスです。実際に使用すると、好みに応じていくつかの調整とカスタマイズを行いました。 myeclipse.iniの最終パラメーターは次のとおりです。
-vmargs
-xmx512m
-xms512m
-xmn192m
-xx：permsize = 128m
-xx：maxpermsize = 128m
-XX：ReservedCodeCachesize = 64M
このパラメーターの設定では、髄髄の応答速度は比較的保証されており、さまざまな遅延遅延の頻度が大幅に減少します。欠点は、永住者が占めるシステムメモリが比較的高いことです。複数の筋髄を同時に開くのが好きな学生は、ニーズと実際の条件に応じて適切な調整を行うことができます。
上記はこの記事に関するものです。すべての人の学習に役立つことを願っています。