2

Mule 3.2 (100 個のスレッドが同時にリクエストを送信) による高負荷の下で、jprofiler を介して、多数のオブジェクト インスタンスが作成され (毎秒約 500 MB)、ヒープの若い領域の 90% 以上のスペースを占有していることを確認できました。 2秒ごとにgcをトリガーするjvm。

なぜ？これは正常ですか？それともバグですか

jvm 引数:

-Xms=2048m -Xmx=2048m -Xmn=768m -XX:PermSize=256m -XX:MaxPermSize=512m -Xss256k -XX:+UseConcMarkSweepGC

ありがとう

4

2 に答える 2

2

Mule が受け取るリクエストごとに、多数のオブジェクトが作成されます (セッション、イベント、メッセージ、多くの場所でクロージャとして機能する匿名クラス)。

さらに、一部のトランスポートは、技術的な必要性に応じて、より多くのオブジェクトを作成し、他のトランスポートはより少ないオブジェクトを作成する場合があります (たとえば、HTTP は、ヘッダー、Cookie を保存するための追加のオブジェクトを作成します...)。

したがって、これはバグではありませんが、機能とは言えません。そして、リクエストごとに作成されるオブジェクトの量を減らすことは、Mule にとって優れたイニシアチブになると思います...

于 2012-05-22T15:30:29.810 に答える
0

アプリケーションの割り当て率を測定するために jProfiler を使用しないでください。jPROfiler はアプリケーションのパフォーマンスに影響を与え、大きなオーバーヘッドをもたらします。

アプリケーションの実際のメモリ統計を観察して計算するには、代わりにgc-logging/jmap/jstatまたはその他のツールを使用する必要があります。

次に、アプリで jProfiler を適度なワークロードで使用して、ヒープ割り当てのプロファイリングと調査を行うことができます。

于 2013-01-05T08:38:37.683 に答える