1



多くのスレッドを作成し、文字列操作に大きく依存するアプリケーションに取り組んでいます。
アプリケーションは一度に 24 時間稼働し、常に非常に応答性が高い必要があります。
オブジェクトの作成を最小限に抑えようとしています。アプリケーションは、現時点では構成なしでうまく機能しています。

しかし、特定の JVM 構成を使用することに利点 (または欠点) があるかどうか、私自身の知識のために疑問に思っていましたか?

ご容赦ください。私は JVM/GC 構成についてはかなり初心者です。

  • マルチスレッドで作業しているときに絶対に使用する必要がある JVM オプションがあるかどうか疑問に思っていましたか?
  • ヒープを構成する必要がありますか?
  • GC も構成する必要がありますか?
  • ガベージ コレクションを最小限に抑える必要がありますか?

    私は読み始めました：http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
    この件に関するヒントは大歓迎です。

    前もって感謝します、

    • 4

    5 に答える 5

    4

    一般に、JVMの微調整に関する最初の最善のアドバイスはそうではありません。デフォルト設定で特定のJVM関連の問題が発生している場合を除いて、それらはそのままにしておきます。

    設定をいじる必要がある場合は、代表的なテストケースを設定し、JProfilerなどの高度なプロファイラーを使用することをお勧めします。

    さらに、HotSpot VMに関する技術文書、特にメモリ管理ホワイトペーパーを実際に読む必要があります。これらはすべてここにあります。

    于 2012-09-25T10:49:56.407 に答える
    3

    正常に動作している場合は、何もする必要はありません。

    アプリケーションが CPU バウンドの場合、多くのスレッドを作成しないでください。理由は、コンテキストの切り替えに多くの時間が浪費されているためです。文字列操作がメモリ内にある場合は、必要なスレッドのみが存在する必要があります

    NCPU = UCPU* (1+W/C)

Where  NCPU--> Number of CPU
UCPU--> Target CPU Utilization
W-->Wait time
C--> Compute time

    したがって、CPU バウンド操作の場合、最大 (CPU 数 +1) スレッドにする必要があります。

    また、Java Concurrency in Practice には、同時実行アプリケーション用に定義された多くのテスト ケースがあります。あなたはそれらをチェックしたいかもしれません。

    于 2012-09-25T10:50:26.360 に答える
    2

    マルチスレッドで作業しているときに絶対に使用する必要がある JVM オプションがあるかどうか疑問に思っていましたか?

    いいえ。

    ヒープを構成する必要がありますか?

    いいえ、ヒープ サイズを適切な値に設定する以外は (-Xmx および -Xms を使用)

    GC も構成する必要がありますか?

    いいえ、「ローポーズ」が特に必要な場合を除きます。現在「応答性」の目標を達成している場合は、デフォルトのスループット コンパイラが最適なオプションです。これらの目標を達成できない場合は、CMS または G1 を検討する必要があります。ただし、一時停止は減りますが、スループットも低下することに注意してください。

    ガベージ コレクションを最小限に抑える必要がありますか?

    いいえ、それは賢明な目標ではありません。あなたの目的はスループットを最大化することであり、GC を最小化しても必ずしもそれが達成されるとは限りません。多くの場合、ガベージの生成を避けるためにアプリケーションに余分な作業をさせるよりも、ガベージを生成する方が効率的です。(また、Peter Lawrey が指摘したように、モードの複雑なコードを作成して維持するための開発者の労力も余分に必要になります。)

    プロファイラーを使用して、アプリケーションが他の生産的な作業に比べて多くの時間 (CPU 時間または経過時間) を費やしているかどうかを確認することをお勧めします。そうでない場合、またはアプリケーションがすでに十分に高速に実行されている場合は、JVM オプションをいじらないでください。

    アプリケーションが将来の負荷の増加に対応できないことが心配な場合は、GC を微調整してもスケーリングされません。より良いオプションは、ハードウェアのスケールアップを調査したり、複数のマシンで作業を行う方法を見つけたりすることです。さらに、GC を調整して現在の負荷でパフォーマンスを向上させると、実際には負荷が増加したときにパフォーマンスが低下する可能性があります。(CMS が追いつかず、回復するために完全なストップザワールド コレクションを実行しなければならない場合に、CMS で発生する問題を考えてみてください。)

    最後に、多くのスレッドを持つことは一般的に悪い考えです。少数のワーカー スレッド (プロセッサ/コアの数にほぼ等しい) を使用し、それらに同時キューなどを介して作業を供給することをお勧めします。

    于 2012-09-25T11:00:51.280 に答える
    2

    マルチスレッドで作業しているときに絶対に使用する必要がある JVM オプションがあるかどうか疑問に思っていましたか?

    デフォルトでは、最適なオプションはすべてオンになっています。HotSpot VM Optionsを見ると、かなりの数が表示されていることがわかり-XX:+ます。これは、デフォルトでオンになっていることを意味します。

    ヒープを構成する必要がありますか?

    おそらく。ただし、可能であればデフォルト設定のままにしておきます。

    GC も構成する必要がありますか?

    おそらく。ただし、可能であればデフォルト設定のままにしておきます。

    ガベージ コレクションを最小限に抑える必要がありますか?

    発生するゴミの量を減らすには努力が必要です。それはある程度の利益をもたらします。自分の時間をどのように使うのが最も効果的か、生成されるゴミの量を減らすためにどれだけの時間を費やすかを決定する必要があります。

    私は常にメモリプロファイラーから始めて、最もガベージを作成している場所を見つけます。すべてを調整しようとするのではなく、リストの一番上から始めてください。これにより、最小限の労力で最大の利益を得ることができます。

    ところで：私は、そうすることが理にかなっている低ガベージおよびオフヒーププログラムの支持者です。私はマイナー GC なしで 1 日実行できるトレーディング システムと、500 GB 以上のデータをオフ ヒープ メモリにロード/使用できるプログラムを作成しました。ただし、それが本当に価値があるかどうかを判断するには、それがエンドユーザーまたはビジネスにどの程度の違いをもたらすかを実証または定量化できなければなりません.

    于 2012-09-25T11:02:10.783 に答える
    1

    過去に、私は同様のサーバー アプリケーションに直面したことがあります。多くの文字列操作、文字列作成、常に非常に応答性が必要です。アプリは、ストレスの多い状況に陥るまで、デフォルトの構成で正常に機能しました。一時停止を少なくするには -XX:+UseConcMarkSweepGC を有効にし、他のパラメーターを微調整して、アプリの動作が希望どおりになるようにする必要があります。短いリストは次のとおりです。

    -XX:+CMSParallelRemarkEnabled
    -XX:+CMSScavengeBeforeRemark
    -XX:+UseCMSInitiatingOccupancyOnly
    -XX:CMSInitiatingOccupancyFraction=nn
    -XX:CMSWaitDuration=300000
    -XX:GCTimeRatio=nn
    -XX:+DisableExplicitGC

    于 2012-10-17T16:21:24.310 に答える