0

RHEL5.3 に Java1.5.0.16 を搭載した weblogic 9.2 サーバーがあり、Web サービスと Alfresco コンテンツ管理システムを展開しています。

HP-UX i11.23 で約 3 年間問題なく実行していましたが、1 か月前に Linux RH5.3 に移行し、ときどき (3 回発生しました) プロセスがますます使用し始めていることに気付きました。マシン上のすべてのメモリとスワップが終了するまで、メモリ。

プロセスは引き続き正常に動作し、GC ログを含むすべてのログ ファイルは (何も起こらなかったかのように) 正常に見えます。

Glance for process ID 25450:

B0000A Glance C.04.70.000 06:54:05 supra2 x86_64 Current Avg High
CPU Util SU | 2% 2% 2%
Disk Util D D | 97% 97% 97%
Mem Util U U | 98% 98% 98%
Swap Util U U | 60% 60% 60%
Resources PID: 25450, java PPID: 25394 euid: 664 User:afspr04
CPU Usage (util): 5.40 Total RSS : 40.6gb
User CPU : 3.60 Text VSS : 56kb
System CPU : 1.80 Data VSS : 66.1gb
Priority : 15 Stack VSS : 2.0mb
Nice Value : 0 Total VSS : 66.5gb
Blocked On : SLEEP
Major Faults : 235
Minor Faults : 164
Processor : 1
Argv1: weblogic.Server
Cmd : /opt/java1.5.0_16/bin/java -Dweblogic.Name=dmcmsserver -Doracle.net.tns_admin=/etc -server -javaagent:/opt/MercuryDiagn
ostics/JavaAgent/DiagnosticsAgent/lib/probeagent.jar -Dprobe.id=supra2_afspr04_dmcms_ear_p4 -Dprobe.group=CMS_SERVER -D
points.file.name=/opt/MercuryDiagnostics/JavaAgent/DiagnosticsAgent/etc/supra2_afspr04_dmcms_ear_p4 -Dcom.wily.introsco
pe.agent.agentName=DMCMS -Xms7g -Xmx7g -XX:PermSize=256m -XX:MaxPermSize=256m -XX:NewSize=1792m -XX:MaxNewSize=1792m -X
X:SurvivorRatio=4 -XX:TargetSurvivorRatio=90 -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Xnoclassg
c -Xloggc:logs/gc.log -Doracle.net.tns_admin=/etc -Dweblogic.Stderr=/app/afspr04/dmcms_ear_p4/dmcmsdomain/logs/online.l
og -Dweblogic.Stdout=/app/afspr04/dmcms_ear_p4/dmcmsdomain/logs/online.log -Damdocs.system.home=/app/afspr04/dmcms_ear_
p4/properties/jesi -Damdocs.messageHandling.home=/app/afspr04/dmcms_ear_p4/properties/jesi -Djesi.config.loader=amdocs.
ecommerce.esi.utils.config.InterfaceConfigXPathLoader -Damdocs.uams.config.resource=config/mvc/ldap ...

pmap は大きな割り当てを匿名の pmap として表示します (大きなものでソートされます):

25450: /opt/java1.5.0_16/bin/java -Dweblogic.Name=dmcmsserver -Doracle.net.tns_admin=/etc -server -javaagent:/opt/MercuryDiagnostics/JavaAgent/DiagnosticsAgent/lib/probeagent.jar -Dprobe.id=supra2_afspr04_dmcms_ear_p4 -Dprobe.group=CMS_SERVER -Dpoints.file.name=/opt/MercuryDiagnostics/JavaAgent/DiagnosticsAgent/etc/supra2_afspr04_dmcms_ear_p4 -Dcom.wily.introscope.agent.agentName=DMCMS -Xms7g -Xmx7g -XX:PermSize=256m -XX:MaxPermSize=256m -XX:NewSize=1792m -XX:MaxNewSize=1792m -XX:SurvivorRatio=4 -XX:TargetSurvivo
00002ab0f8000000    10518548    rwx--   [anon]
00002ab798009000    8388612 rwx--   [anon]
000000005fcce000    8038976 rwx--   [anon]
00002aac7aab0000    7602176 rwx--   [anon]
00002aaf74000000    5259284 rwx--   [anon]
00002ab688000000    4194308 rwx--   [anon]
00002aae4b930000    1684124 rwx--   [anon]
00002aab80000000    1314836 rwx--   [anon]
00002aab20000000    655376  rwx--   [anon]
00002aac28000000    532488  rwx--   [anon]
00002aac50000000    524292  rwx--   [anon]
00002aaaec000000    327696  rwx--   [anon]
00002aaad8000000    131088  rwx--   [anon]
00002ab658000000    131060  rwx--   [anon]
00002ab0dc000000    131044  rwx--   [anon]
00002aaacc2f5000    114708  rwx--   [anon]
...
total 69733292K 

誰かが似たようなことに遭遇しましたか?

ありがとう、オズ

4

2 に答える 2

0

使用しているサーバーのCPU/RAMは何ですか?WLS 9.2のRHEL互換性マトリックスを参照し、JDK/CPU構成がサポートされている組み合わせであることを確認する必要があります。また、それがオプションである場合は、JRockitをJVMと見なすことができます。最後に、最大ヒープスペース(-Xmxおよび-Xms)を下げて、サーバーがより安定しているかどうかを確認します。

于 2010-08-18T05:08:06.777 に答える
0

ここでは、別の OS (Sun Solaris 10 - 32 ビット) で同じ種類の問題がありますが、共通点があると思います: Introscope です。

ネイティブ ライブラリ (*.so は JNI 経由でアクセス) を使用しているため、メモリを割り当てすぎていると考えられます (メモリ リーク?)。

私の主張を理解するために、この場合、JVM プロセスのメモリについて明確にする必要があることがあります。Java プロセスのメモリ全体は、ネイティブと Java の 2 つの異なる部分に分割されます。

Java 部分 (ガベージ コレクターによって管理される部分) のメモリは、標準の JVM API を介して監視できます。Java では、JVM プロセスのメモリのこの部分しか監視できないことに注意してください。ヒープ (eden と 2 つの生存者)、oldgen、permgen が含まれています。メモリのこの部分は通常最大のものです。これが、それを監視する方法がある理由です。残りの部分には何もありません。

プロセスのメモリの残りの部分であるネイティブ部分は異なります。これは、ネットワーク ソケット/バッファ、ファイル記述子/バッファ、GC の実際のデータ構造とバッファ、ネイティブ ライブラリ バッファ、JIT コンパイラによってコンパイルされたネイティブ コード、およびその他の内部 JVM 固有のもので構成されています。JVM の実行可能コードとネイティブ ライブラリもあります。通常、デバッガを使用する以外に、この部分を参照する標準的な方法はありません (ほとんどの場合、まったく方法がありません)。

Wily / Introscope のネイティブ ライブラリについて C&A に問い合わせたところ、次のように説明されました。

  • メモリを動的に割り当てます。
  • そのメモリ消費を制限する方法はありません。
  • そのメモリ消費量を予測する方法はありません。
  • Introscope はその他すべてに Java Agent API を使用しているため、基本システムの特定の測定値 (OS フラグ、CPU 負荷、総空きメモリ、プロセス数など) を収集するためにのみ Wily によって使用されます。

アプリケーションの 99% では、メモリの「ネイティブ」部分 (非 Java 部分) は、Java 部分と比較して無視できます。

しかし、ここで Introscope をゲームでプレイすると、ネイティブ部分が任意に大きくなり、プロセスのメモリ スペースを限界まで消費する可能性があるため、状況が異なります。

ここで、これらのシステム固有の値は私たちにとってあまり興味深いものではないと結論付けました.mem、free、top、taskmanagerなど、他の方法でそれらを取得する方法があるため、これは多くの人に当てはまると思います.削除することにしました。単に。

これが最良の選択肢だと思います。

試してみて、メモリの問題が解決したかどうか教えてください.

于 2012-02-03T09:58:00.597 に答える