11

OK、私は特定のアプリケーションと何とか何とか何とかベンチマークする必要があることを理解していますが、

-Xmx のデフォルトの JVM 設定、デフォルトのガベージ コレクタなどは、ほとんどの典型的な Java プログラムにとって妥当なデフォルトであり、慣用的な Scala コードには適切ではない可能性があります (慣用的な Scala はより多くの「ガベージ」を生成する傾向があるため)。 」）。

そのため、最初に推奨されるオプションを探しています。典型的な Scala プログラムでは、より高い -Xmx 設定が必要ですか? 特定の JVM は他よりも scala に適していますか? 別のガベージ コレクター (-XX:+UseParallelGC と XX:+UseConcMarkSweepGC) は通常、Java の通常のデフォルトよりも、Scala の安全/優れた/高速な推測/ベット/デフォルトですか? Scala コードに関して具体的に考えるべき他のオプションはありますか? また、その方法は?

より多くの一時オブジェクトが生成されるため、通常、デフォルトで「若い」世代により多くのスペースを与える必要がありますか? それとも、より頻繁なガベージ コレクションを強制するために、通常、若い世代に与えるスペースを少なくする必要がありますか? 他の世代はどうですか？

もちろん、特定のアプリ用にこれらのことを調整する必要がありますが、一般的に、典型的な Scala プログラムの場合、私の出発点は Java の場合とは異なる可能性があると推測しています。

特定のアプリケーションでメモリ不足エラーや「GC オーバーヘッドの制限に達しました」というエラーが発生したり、アプリがガベージ コレクションの一時停止に時間がかかりすぎたりすることがあります。オプションを微調整することでこれらの問題をある程度回避できますが、他の経験、一般的な原則、および出発点について聞きたいです。

4

2 に答える 2

3

Eclipse IDEのJVMおよびGC設定を最適化することで私が見つけた1つのことは、世代サイズが大きいということは、最終的にそれらを収集するときに大きな一時停止を意味します。

一時停止は、インタラクティブなアプリケーションにとって明らかに大きな煩わしさです。ここでの意味は、大きな最大値を使用することですが、大きな最小値を強制することはありません。

XX：+ UseParallelGCとXX：+ UseConcMarkSweepGCをかなり集中的に比較しましたが、それは以前のコンピューターでした。そのマシン（シングルプロセッサ）でXX：+ UseConcMarkSweepGCを使用することになりましたが、マルチコアマシンの場合は明らかにParallelが最適です。

非常に興味深いGC-チューニングのヒント：

IIRC、私は-XX：SurvivorRatio = 2または-XX：SurvivorRatio = 3の「低い値」が大幅なパフォーマンス上の利点を提供することを発見しました。私が試した他のすべてのオプションは、認識できる効果がありませんでした。

于 2012-10-07T09:14:03.277 に答える
3

これはscalaユーザーからのものなので、純粋に個人的な経験に基づいています。つまり、少しの努力で長い道のりが得られることがわかったので、JVMの最適化をかなり行う傾向がありますが、scalaに固有のものは見つかりませんでした。

あなたが言ったように、JVMのデフォルトはせいぜい合理的です。適切なヒープサイズの設定、適切なGCの選択、サーバーVMの使用、世代のサイズ設定などはすべて、プレーンJavaアプリの場合と同じようにscalaアプリケーションのパフォーマンスを向上させます。これは、javaとscalaのプロファイルが同一であるということではなく、実際のアプリケーションがはるかに大きな影響を与える可能性があるということです。

理論的な側面から私が重要だと思う唯一のことは、新しい世代のサイズです。scalaはより短命のゴミを生成する可能性があり、より大きな新しい世代はここでVMを少し助ける可能性があります。

于 2012-09-13T09:52:38.880 に答える