34

私はAlfrescoを実行するためのJVM構成オプション、主にAlfrescoWikiのこのドキュメントを見ています。推奨事項の1つは、JVMフラグとを使用することです。これの正当化は次のとおりです。-Xcomp-Xbatch

ホットスポットでクラスをプリコンパイルする場合は、[-Xcompおよび-Xbatch]を追加できます。ただし、これによりサーバーの起動時間が大幅に増加しますが、後でヒットする可能性のある欠落している依存関係が明らかになります。

とフラグについて他の場所で読んだことから、それらが本当に何らかの利益をもたらすかどうか疑問に思っています。-Xcomp-Xbatch

  • -XcompHotSpotを取得して、最大限の最適化を使用してすべてのコードを事前にコンパイルします。これにより、VMがシステムの標準実行を通過するプロファイリングよりも優先されます。
  • -Xbatchバックグラウンドコンパイルを停止します。これは、コンパイルが完了するまでコードがブロックされる原因となったスレッドを意味します。ただし、コンパイルが終了した後、以前にブロックされたスレッドはコンパイルされたコードを実行せず、解釈されたコードを実行します。これはJava6（Mustang）での変更でした。Mustang以前は、-Xbatchフラグの存在によってコンパイルがブロックされたスレッドは、コンパイルが完了するとすぐにコンパイル済みコードで実行されることが保証されていました。-Xbatchしたがって、フラグの推奨は、古いVMでAlfrescoを実行した遺物であると推測しています。

誰か考えがありますか？私の傾向は、これら2つのフラグを取り除き、VMに依存して問題を解決することです。

2つ追加したいのですが、まず、これをテストするためのAlfrescoインスタンスにまだアクセスできていません。次に、他のマシンを見て、Alfrescoをホストしているマシンの仕様がわかりません。構成オプションは64ビットVMである必要があります。それにもかかわらず、おそらく一般的なHotSpotチューニングの観点から、コミュニティがいくつかの有用な情報を提供することを願っています。

4

2 に答える 2

28

一般的に言えば、HotSpotコンパイラにそれ自体を調整させることが常に望ましいです。サーバーVM（-server）を使用する場合でも、64ビットおよび一部の「サーバークラス」マシンではデフォルトです。

-Xbatchは、あなたが指摘したSteve Goldmanのブログで説明されているように、主にデバッグを目的としていました。

したがって、-Xbatchスイッチは、マスタング以前の時代でも特に有用なスイッチではありません。実行の予測可能性と再現性が向上する傾向があるため、jvm開発者にとっては多少便利です。

-Xcompは、効率的なコンパイルのために情報を収集する機能を削除します。アレックスターナーの投稿から：

-Xcompは、パフォーマンスの観点からは良い考えだと思うかもしれません。しかし、そうではありません！JITコンパイラは、コンパイル前にこれらの1000回の反復を使用して、最適な効率を得るためにメソッドをコンパイルする方法に関する情報を収集します。-Xcompはその機能を削除するため、実際にパフォーマンスの低下を確認できます。

パフォーマンスを考慮せずに、これらのフラグを使用して欠落している依存関係を検出することは見たことがありません（また、一部のコードがまだ解釈されている場合は機能しない可能性があります）。

于 2010-08-09T11:18:30.497 に答える
0

Alfresco は、エンタープライズ コンテンツ管理です。フラグがそのパフォーマンスにどのように影響するかはわかりません。それから同じページのメモは言った..

-- ただし、これによりサーバーの起動時間が大幅に増加しますが、後でヒットする可能性のある不足している依存関係が強調されます。...

私見、著者は実際にはパフォーマンスの向上を意味していませんでした。彼/彼女は、すべての依存関係が整っていることを確認する手段としてそれを書きました。

于 2010-08-07T18:01:13.763 に答える