3

Web アプリのメモリ使用量を減らす方法についてサポートが必要です。だから私は私のウェブサーバーにもっと収まることができます。

だから私はEclipse Heliosで開発し、Apache tomcat Serverで実行するJSF 2.0でJava Webアプリを構築しています。また、これらのwarファイルを展開するTomcatを備えた専用の仮想サーバーもあります。webApp のサイズは約 35MB (多くの jar などがあります) ですが、Tomcat Web サーバーにデプロイすると、約 300MB の RAM が必要であることがわかります。これは正常ですか? 私の専用サーバーには 2 GB の RAM しかなく、通常は 1 GB を使用します。そのため、3 つのアプリを展開するとすぐに OOM エラーが発生します。permgen OOM と沼地のメモリ不足エラーが発生しました。これを修正するために、MaxPermGen を約 1 ギグに上げ、サーバーを再起動して沼地のスペースを取り戻しました。そのため、より小さな古いアプリ (約 15MB) をデプロイしようとしましたが、使用するメモリはかなり少なくなりました。

今、私はこのスタックオーバーフローの質問を見つけました、それは私のケースに適用できますか? もしそうなら、Tomcat サーバーの共通フォルダーはどれですか? 誰かが以前にこれをやったか、より効果的でそれほど複雑ではない別のアプローチを持っていますか?

アイデアやコメントは大歓迎です。ありがとう!

マイ

4

3 に答える 3

4

これらの war ファイルをデプロイします。webApp のサイズは約 35MB です (多くの jar などがあります)。

使用するファイルだけがメモリを占有します。使用しないクラスを削除すると、ディスク容量は節約されますが、メモリは節約されません。

しかし、Tomcat Web サーバーにデプロイすると、約 300MB の RAM が必要であることがわかります。これは正常ですか?

サーバーに 300 Mb の空き容量がある場合は、それをすべて使用します。3 GB の空き容量がある場合は、それもすべて使用する可能性があります。サーバーを現実的な方法で使用し、フル GC を実行した後、使用量を確認する必要があります。

1 GB の RAM がある場合、OOM エラーを発生させずに、より多くのアプリを Web サーバーに収めたいと考えています。

各アプリケーションが実際に必要とするメモリ量を決定する必要があります。または、1 GB の価格が約 20 ドルなので、追加のメモリを購入する必要があります。(メモリのコストがはるかに高いホストされたソリューションだと思います;)

于 2012-08-28T15:36:19.473 に答える
3

通常のメモリ使用量は、webapp とその実行内容によって異なります。@Peter Lawrey が言うように、WAR ファイルのサイズと使用されるメモリの量の間には直接的な関係はありません。

はい、一般的な JAR ファイルを WAR から共有ライブラリ フォルダーに移動するアプローチは、メモリを削減しますが、全体的に大きな違いはないかもしれません。ライブラリ フォルダ名については、 Tomcat7 のドキュメントを参照してください。

共有ライブラリ内のクラスは、. ただし、いずれかのクラスに静的な状態がある場合、その状態がすべての Web アプリケーションで共有されていることがわかります。これにより、ある webapp のオブジェクト/タイプが別の webapp に表示され、問題が発生する可能性があります。

1 GB の RAM がある場合、OOM エラーを発生させずに、より多くのアプリを Web サーバーに収めたいと考えています。

Java はメモリを大量に消費する傾向があり、現実的には、一定量のメモリ (および労力) で実行できることには限界があります。結局のところ、期待を下方修正する必要があると思います...または、より多くのメモリを備えた仮想を支払う必要があります.


この道を進む前に、Java メモリ プロファイラを使用して、Web アプリケーションの設計と実装に大量のメモリを使用する原因があるかどうかを確認することをお勧めします。

于 2012-08-28T16:23:47.377 に答える
2

war ファイルのサイズによって、アプリケーションが消費するメモリ量が決まるわけではありません。また、Tomcat で 5 つのアプリケーションを起動できたとしても、それらが 3 週間後に実行されるとは限りません。

このためには、各アプリケーションを個別にロード テストして、メモリ フット プリント (長期的に必要なメモリ量) を判断する必要があります。

このためには、次のことが必要です。

  • アプリケーションを使用する同時ユーザーの最大数を見積もる
  • すべてのユーザーにテスト ユース ケースを割り当てます。たとえば、最大 100 人の同時ユーザーがいて、10 人が登録し、10 人が何かを検索し、10 人がデータを入力している場合などがあります。
  • JMeterGrinderなどのツールを使用して、すべてのユース ケースのテストを記述/記録します。
  • Java メモリ プロファイラーを使用して、負荷テスト中にメモリ使用量、ガベージ コレクションなどを監視します。

Load Generator をしばらく実行した後、使用メモリは 1GB、1.5GB などのどこかで安定するはずです。これがメモリ フットプリントです。ハードウェアがこの量のメモリを提供していることを確認する必要があります。

が安定しない場合は、メモリ リークが発生し、最終的にOutOfMemoryError. しかし、それは別のトピックです。

さまざまな jvm メモリ構成を試し、アプリケーションのパフォーマンス (TPS 番号) にも注意を払います。上記のツールによって提供されます。

これは氷山の一角にすぎませんが、負荷とパフォーマンスのテストは密度の濃いトピックです。

于 2012-08-28T16:30:28.460 に答える