2

これがServerFaultに適しているかどうかはわかりませんが、私は管理者ではなく開発者なので、SOを試してみることにしました。

マルチサーバー構成を安定させるのにかなり長い間苦労してきました。先月末、2台のサーバーセットアップ（それぞれ1つのインスタンス）でCF7.0.2で実行していました。その時点で、インスタンスが自動的に再起動する前に、インスタンスごとに約1週間の稼働時間を得ることができました。月の初めからCF9にアップグレードし、1日マルチリスタートでスクエア1に戻りました。

現在の構成は2台のWin2k3サーバーで、サーバーごとに2つのインスタンスで4つのインスタンスのクラスターを実行しています。この時点で、これは不適切なJVM設定が原因であると確信しています。

私たちは彼らと一緒にいじっています、そしていくつかは他のものより安定していますが、私たちはそれを完全に正しくすることは決してありませんでした。

デフォルトから：

java.args=-server -Xmx512m -Dsun.io.useCanonCaches=false -XX:MaxPermSize=192m -XX:+UseParallelGC -Dcoldfusion.rootDir={application.home}/

現在へ：

java.args=-server -Xmx896m -Dsun.io.useCanonCaches=false -XX:MaxPermSize=512m -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:+UseParallelGC -Dcoldfusion.rootDir={application.home}/ -verbose:gc -Xloggc:c:/Jrun4/logs/gc/gcInstance1b.log

FusionReactorで監視するだけで、デフォルトの512MB以上が必要であると判断しました。平均して、消費されるメモリの量は300MBの半ばで推移しており、高負荷では700MBまで低下する可能性があります。

クラッシュのほとんどは、jrun4 / bin / hs_err_pid*.logに記録されます。常に「スワップスペースが不足しています」

昨日の投稿の下部に、hs_errとガベージコレクターのログファイルへのリンクを添付しました。

関連する部分は（私が思うに）これです：

Heap
 PSYoungGen      total 89856K, used 19025K [0x55490000, 0x5b6f0000, 0x5b810000)
  eden space 79232K, 16% used [0x55490000,0x561a64c0,0x5a1f0000)
  from space 10624K, 52% used [0x5ac90000,0x5b20e2f8,0x5b6f0000)
  to   space 10752K, 0% used [0x5a1f0000,0x5a1f0000,0x5ac70000)
 PSOldGen        total 460416K, used 308422K [0x23810000, 0x3f9b0000, 0x55490000)
  object space 460416K, 66% used [0x23810000,0x36541bb8,0x3f9b0000)
 PSPermGen       total 107520K, used 106079K [0x03810000, 0x0a110000, 0x23810000)
  object space 107520K, 98% used [0x03810000,0x09fa7e40,0x0a110000)

それから、PSPermGenがいっぱいであることがわかります（ほとんどのログはクラッシュする前に同じように表示されます）。そのため、MaxPermSizeを増やしましたが、合計は107520Kと表示されます！??！

ここにいるのはjRunの専門家ではないので、次に何を試すかについてのヘルプやアイデアさえも大歓迎です!!

ログファイル： 申し訳ありませんが、sendspaceが最もフレンドリーな場所ではないことを知っています-ログファイルに関する他のホストの提案がある場合は、私に知らせて、投稿を更新します（SOはそれらをインラインで嫌いです、それはのフォーマットを爆破しますポスト）。

4

2 に答える 2

2

これは、アプリケーションの構築方法に起因するさまざまな原因 (アプリケーションまたはサーバー スコープの型にはまらない使用法、不適切なデータベース ドライバーと接続管理、巨大な XML ファイルの解析、CFHTTP またはその他の外部リソースの使用、ネイティブ セッション レプリケーション?) コーディング プラクティス (どこでも var スコープ?) とサーバーの CPU の種類。多くの分析を行わずに、特効薬の JVM 設定を思いつくことはほとんどありません (そして、おそらくそうであったとしても)。しかし、まず第一に、なぜこれほど異常に大きな PermGen を持っているのでしょうか? 独特のパターンのようですが、もちろん私はあなたのアプリについて何も知りません。

いくつかの異なるガベージコレクターを試しても、失うものはほとんどないようです。JVM のバージョンに適している場合は、次を試してください。

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC

そして追加します：

-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

これは、大きな PermGen の管理に役立つ場合があります。これらを試す場合は、XX:+UseParallelGC を忘れずに取り出してください。

于 2010-05-20T03:06:43.490 に答える
1

少し更新。私はさまざまなGCを試しましたが、しばらくの間システムを安定させたものもありましたが、それほど頻繁ではありませんでした。それで私は掘り下げ続け、OS自体が要求されたメモリの割り当てを拒否したときにJVMが「スワップスペース不足」をスローすることを最終的に発見しました。

これは通常、最大メモリがすでにJVMプロセスに割り当てられている場合に発生します。これは、jrunオーバーヘッド、JVM自体、すべてのライブラリ、ヒープ、およびスタックです。大量のリクエストが生成されている場合、リクエストはスタック上に存在するため、スタックはどんどん大きくなります。各スレッドのサイズは、JVMのOSとバージョンによって異なりますが、-Xss引数を使用して制御できます。私は64kに減らしたので、java.argsは次のようになります。

java.args=-server -Xmx768m -Xss64k -Dsun.io.useCanonCaches=false -XX:MaxPermSize=512m -XX:+UseParallelGC -Dcoldfusion.rootDir={application.home}/ -verbose:gc -Xloggc:c:/Jrun4/logs/gc/gcInstance2a.log

これまでのところ、すべてが安定しており、6日間目立った速度低下はありません。これは、アプリケーションが稼働しているのをこれまでに見た中で間違いなく最長です。リクエストサイズを小さくしすぎると、OOMエラーではなく、ログにスタックオーバーフローエラーが表示されるようになります。

私の次のステップはMaxPermSizeを微調整することですが、これまでのところとても良いです！

于 2010-06-02T15:01:44.953 に答える