Playframeworkのメモリ使用

再生フレームワークのメモリ使用量に関する簡単な質問。私は680768 kBのメモリを使用している実例を持っています。そのほとんどはスワップにあります。Playframeworkのメモリ使用

（仮想）サーバは約750 MBですが、MySQLサーバと12個のApache仮想サーバも実行します。短期間に一時的に未応答（または非常に遅い）になることがあります。私はそれが（CPUではない）スワッピングのためだと思います。

フレームワークにはそのようなメモリが必要ですか？ JVMパラメータ-Xmx256m程度でメモリ使用量を制限することができますが、どのような値を入れるべきでしょうか。

これはPlayによる使用方法です。前と開始後：

のJava：~~~~~バージョン：1.6.0_26ホーム： /usr/lib/jvm/java-6-sun-1.6.0.26/jre 最大メモリ：194641920無料メモリ：11813896 合計メモリ：30588928個の利用可能なプロセッサ：再起動後に2

：Javaの：~~~~~バージョン：1.6.0_26ホーム： /usr/lib/jvm/java-6-sun-1.6 .0.26/jre 最大メモリ：194641920無料メモリ：9893688 合計メモリ：21946368 利用可能なプロセッサ：2

出典

2012-02-12 Luuk D. Jansen

このような質問に答えることは非常に困難です。それは非常に多くの要因（複雑さ、キャッシングなど）に依存します - 再生！ステートレスな設計を奨励します。そのため、メモリ使用率は少し高いようです（ただし、Javaでは驚くにはあたらない）。サーバーを再起動してメモリフットプリントが下がったかどうか確認しましたか？また、メモリダンプは、このメモリがどこに割り当てられているかのヒントを与えるかもしれません。 –

は、再生ステータスがあなたに与えるメモリ出力を（ステータスの開始時に）送信できますか？私の場合は、問題なしで-Xmx64Moを使って遊ぶアプリケーションを実行しています。メモリがさらに必要な場合は、コードにメモリリークが発生する可能性があります。 –

質問に追加します。現在の665 MBのうち71 MBのみがアクティブメモリにあります（上部）。 665は十分に安定しているようです。プレイのレトルト後！アプリケーション（および少なくとも1つの要求）は、topによって報告されたメモリが524mであることを示します。（質問にPlay！によって報告されたメモリ使用量を入力してください） –

それは多くのことに依存しますが、ネイティブの割り当て、ヒープとヒープ以外のメモリ空間のためにいくつかのメモリが必要です。

再生ステータスでは、ヒープは30588928バイトしか消費しませんが、起動時にはヒープに194641920が割り当てられます。ヒープ割り当てを制限するには、-Xmx64Mを使い始めることができます。

約128MoのRAMを保存できますが、javaもjvm用にメモリを割り当てますので、プロセスのフットプリントは64Mo以上になります。プラットフォームにもよりますが、少なくとも200/250になりますMo.

ヒープを64Moに制限してみてくださいが、750Moはjvmとmysqlを実行するには不十分です。

スワップをJavaで使用しないでください。メモリが1つのブロックに割り当てられているため、ヒープ全体をスワップ/スワップするためです。

出典

2012-02-13 17:07:30

遅い反応で申し訳ありませんが、私はその違いを見るために適切なテストを設定するチャンスを得られませんでした。 Playを実行するための最高の、あるいはまさにそのようなコマンドです。 -Xmx64Mで？ –

application.confファイルに、「jvm.memory = -Xmx64M」という行を追加します。 –

これを実行すると、これがドロップされました。最大メモリ：249364480 無料メモリ：20543688 合計メモリ：59219968個の利用可能なプロセッサ：2 トップが与える：最大メモリ：：（仮想環境）627メートル（RES）185メートル変更後変更前64880640 無料メモリ：2793576 合計メモリ：53366784個の利用可能なプロセッサ：2 トップ（汚れ）を与える470メートル（RES）199メートルだから-Xmx64mは、フレームワークを損なうことなく入れるための正しい値も取るでしょうか？ –

あなたが報告している680768 kBのメモリは、psやタスクマネージャなどのOSツールからのものと仮定しています。 JVMで使用されているメモリの総量によって、アプリケーションの一時的なフリーズが発生していません。原因となるのは、JVMガベージコレクタがフルGCを実行しているためです（同時GCが設定されていない限り、フルGCが実行されているJVM内のすべてのスレッドを一時停止します）。

playframeworkを実行しているJVMを-verbosegc -XX：+ PrintGCDetailsで実行して、GCが何をしているのかを確認する必要があります。

あなたの質問「使用しているメモリの量は、アプリケーションが事前要求ベースで行っていることによって決まります。また、JVMは、ヒープを実行させ、GCサイクルを実行してヒープをクリーンアップします。よく動作するJVMアプリケーションは、GCグラフに鋸歯状パターンを表示する必要があります。

ホットスポットVMを使用している場合は、使用しているJVMがわからないので、JVMチューニングガイドをお読みください。 http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html JVMチューニングガイドを読む前に、以下のGCの概念を理解する必要があります。

マークとパラレルガベージコレクション
同時ガベージコレクション

ガベージコレクションをスイープマーク、

コピーコレクタをスイープし、コンパクトなガベージコレクション

世代別ガベージコレクション

http://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795/はプロですこのテーマに関する素晴らしい本です。

使用できるホットスポットJVMに付属するいくつかの無料ツールには、jconsoleとjvisualvmがあります。 jvisualvmにはVisualGCという素晴らしいプラグインがあり、ホットスポットVMがメモリをどのように管理しているかを覚えています。

出典

2012-02-12 19:51:54 ams

答えて

関連する問題