Sun Web Server 7サービング.jsp - エデンのスペース動作 - 考えられるメモリリーク

Question

私の会社は最近、コンテンツ管理ソリューションとしてAlfrescoに移籍しました。コンテンツの一部が動的であるため（別の.jspファイルに含まれている.jspファイルは、Alfresco からXMLとして公開されたサイトマップを読み取り、24時間の結果をキャッシュします）、生成されるファイルは.jspでrsyncされ、 Sun Web Server 7サーブレットコンテナ。

各ページには、ランタイムディレクティブを使用する に含まれるヘッダー、メニュー、およびフッターがあります。私の理解は、最初の要求がindex.jspになされたときに、コンパイルされたjspsの数が存在するということです。 index.class,header.class, menu.classおよびfooter.classである。要件はサーブレットコンテナで1回コンパイルして、ソースjsp（Alfrescoによってプッシュアウトされたもの）をx秒ごとに変更するかどうかをチェックすることです。

Webサーバ自体は、Sunのドキュメントで推奨されているように、次のパラメータを使用して生産準備ができて（default-web.xml）configredされました：checkIntervalパラメータが60に設定されるべきであることを

<init-param> 
    <param-name>development</param-name> 
    <param-value>false</param-value> 
</init-param> 
<init-param> 
    <param-name>checkInterval</param-name> 
    <param-value>0</param-value> 
</init-param> 
    <init-param> 
    <param-name>fork</param-name> 
<param-value>true</param-value> 
</init-param> 
<init-param> 
    <param-name>mappedfile</param-name> 
    <param-value>false</param-value> 
</init-param> 
<init-param> 
    <param-name>suppressSmap</param-name> 
    <param-value>true</param-value> 
</init-param> 
<init-param> 
    <param-name>classdebuginfo</param-name> 
    <param-value>false</param-value> 
</init-param> 
<init-param> 
    <param-name>trimSpaces</param-name> 
    <param-value>true</param-value> 
</init-param> 

ますが、これをやってWebサーバーが起動しなくなってしまいます（私は理由を理解できませんでした）。このための残念な回避策は で、次にdevelopmentをtrueに設定することをお勧めします。

-server -Xrs -Xmx2048m -Xms2048m -Xmn2024m -XX:+AggressiveHeap -XX:LargePageSizeInBytes=256m -XX:+UseParallelOldGC -XX:+UseParallelGC -XX:ParallelGCThreads=8 -XX:+DisableExplicitGC 

パフォーマンステスト、我々は2ギガバイトに頻繁にスパイクエデンスペース（当社静的の合計サイズを見ている時：

サーブレットコンテナは、（Sunのドキュメントで推奨再びとして）次のJVM設定で構成されています内容はおよそ200MBであり、私たちの テストは少数のページに対するものです）。マイナーなコレクションがたくさんあります。オブジェクトを素早くTenuredの空間に押し込んで、本当に回復することはありません。多くの完全なGCが得られます （生存者のスペースも90MBから2バイトに縮小されます。 。これが最大の問題点です。私たちの開発者の誰も これは正常な動作だと思いますが、そのメモリがどこに行くのか説明できません。

私たちが見ている他の問題は、スレッド数です。各HTTP要求がサーブレットで新しいスレッドを生成すると、ロードに比例して増加することが予想されます（実行時にjsp:includeを実行すると、新しいスレッドが各サーブレット内にも作成されるとも考えられます）（RequestDispatcher.include()コンパイル済みのjsp ）しかし、各リクエストが処理されると、スレッドは終了し、新しいスレッドが生成されます。 これは正しい仮定ですか？スレッド数は負荷に関係なく停止して増加するようです。

Answer 1

ヒープ使用グラフののこぎり模様は正常であり、メモリリークを示していません。メモリリークは、ノコギリ歯の下限が上向き時間の経過と共にアース。

ただし、常にフルGCを実行することが懸念され、ストレージリークが発生している可能性があります。メモリプロファイラーで実行して、漏れているものがあるかどうかを確認してください。

私はリークを引き起こしている可能性があることを知っていると感じています。私はあなたが動的にJSPを生成していると言ったと思います。コンテナは新しい（または更新された）JSPを見つけるたびに、Javaクラスを生成し、クラスをコンパイルしてからバイトコードをロードします。注意しないと、古いクラス/古いバージョンのクラスは引き続き到達可能でリークします。

---

また、スレッドのカウントが負荷の上昇と下降を期待しません。まともなWebコンテナは、着信要求を処理するために使用されるスレッドのプールを維持します。スレッドプールには通常、上限が固定されているため、要求の嵐がスレッド数の爆発を招かず、リソースの使用や競合の問題が発生します。