1

私は基本的な Struts ベースのアプリケーションに取り組んでおり、メモリに大きなスパイクが発生しています。ユーザーごとに 1 つの要求が JVM ヒープ メモリに 3MB 追加されることを通知する監視ツールがあります。早期のガベージ コレクションを促進したり、メモリを解放したり、パフォーマンスを向上させるためのヒントはありますか?

アプリケーションは基本的な Struts アプリケーションですが、JSP レポートの行数が多いため、多数のオブジェクトが作成される場合があります。しかし、それはあなたが前に見たことがないものではありません。

  1. 一連のデータベース クエリを実行します。
  2. 直列化された POJO オブジェクト Bean を作成します。これは行を表します。
  3. 配列リストに行を追加します。
  4. アクションが呼び出されたときに、配列リストをフォーム オブジェクトに設定します。
  5. JSP ロジックは ActionForm からのリストを繰り返し処理し、データがユーザーに表示されます。

注:
1. フォームはセッション スコープ内にあり、データの配列リストである可能性があります (これは問題である可能性があります)。2. POJO Bean には、またはデータ
が混在する 20 ほどのフィールドが含まれます。StringBigDecimal

レポートには、300 から 1200 程度の行を含めることができます。したがって、少なくともその数のオブジェクトが作成されます。

4

3 に答える 3

2

あなたが提供した情報を考えると、通常、結果のために 1 から 2 メガバイトのデータをロードしていると推測できます: 750 行 * 20 フィールド * 1 フィールドあたり 100 バイト = 1.4 Mb。ここで、データベースと最終的なマークアップの間に必要なすべての一時オブジェクトを検討してください。3 Mb は驚くべきことではありません。

そのメモリがリークしたように見える場合にのみ心配します。つまり、若い世代空間の次のガベージ コレクションでは、これらのオブジェクトがすべて収集されるわけではありません。

于 2008-12-04T22:37:19.093 に答える
0

問題は、大量のメモリ空間を割り当てる必要がある ActionForm の arraylist にあると思います。クエリ結果を応答に直接書き込みます。結果セットから行を読み取り、応答に書き込み、次の行を読み取り、書き込みなどを行います。MVC ではないかもしれませんが、ヒープには適しています :-)

ActionForms は CRUD 操作には問題ありませんが、レポートには ... そうは思いません。

注: ActionForm に scope=session がある場合、インスタンスは (巨大な配列リストと共に) セッションが期限切れになるまで生き続けます。scope=request の場合、インスタンスは GC で使用できます。

于 2009-04-27T15:27:39.573 に答える
0
  1. リスト項目

レポートを Web アプリケーションでレンダリングするように設計する場合は、データベースからフェッチされるレコードの数を考慮してください。

レコード数が多く、レコードセット全体が多くのメモリを消費している場合は、レポートのページネーションの使用を検討してください。

ガベージ コレクタを明示的に呼び出さないでください。これには、次の 2 つの理由があります。

  1. ガベージ コレクションは、メモリ全体をスキャンするため、コストのかかるプロセスです。

  2. 本番サーバーのほとんどは、明示的なガベージ コレクションを回避するために JVM レベルで調整されます。

于 2008-12-26T04:18:48.703 に答える