0

我们在 RHEL5.3 上有一个带有 Java1.5.0.16 的 weblogic 9.2 服务器，我们在其上部署了一个 Web 服务和一个 Alfresco 内容管理系统。

我们在 HP-UX i11.23 上运行了大约 3 年，一个月前我们迁移到 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

我们在使用不同的操作系统（Sun Solaris 10 - 32 位）时遇到了同样的问题，但我看到了一个共同点：Introscope。

我们怀疑它分配了过多的内存（内存泄漏？），因为它使用了本机库（*.so 通过 JNI 访问）。

为了理解我的观点，在这种情况下，关于 JVM 进程的内存，我需要澄清一些事情：Java 进程的整个内存分为两个不同的部分，即本机和 Java 部分。

Java 部分（由垃圾收集器管理的部分）的内存可以通过标准 JVM API 进行监控。请记住，在 Java 中，您只能监控 JVM 进程的这部分内存。它包含堆（伊甸园和 2 个幸存者）、oldgen、permgen。这部分内存通常是最大的，这就是为什么有办法监控它，而其余的却没有。

进程的其余内存，即本机部分，是不同的。它由网络套接字/缓冲区、文件描述符/缓冲区、GC 实际数据结构和缓冲区、本机库缓冲区、JIT 编译器编译的本机代码以及其他一些内部 JVM 特定的东西组成。还有 JVM 和本机库的可执行代码。除了使用调试器外，通常没有标准的方法（通常根本没有办法）来查看这部分。

在向 C&A 询问 Wily / Introscope 的本地库后，他们向我们解释说：

  • 它动态分配内存；
  • 没有办法限制它的内存消耗；
  • 没有办法预测它的内存消耗；
  • Wily 仅使用它来收集底层系统的特定测量值（例如操作系统标志、CPU 负载、总可用内存、进程数……），因为 Introscope 将 Java 代理 API 用于其他所有方面。

对于 99% 的应用程序，内存的“本机”部分（非 Java 部分）与 Java 部分相比可以忽略不计。

但是在这里，随着 Introscope 在我们的游戏中运行，事情变得不同了，因为本机部分可能会变得任意大，并且会占用进程的内存空间达到极限。

我们在这里得出的结论是，这些特定于系统的值对我们来说不是很有趣——我认为你们中的许多人都是这种情况，因为还有其他获取它们的方法：mem、free、top、taskmanager……——所以我们决定删除它。简单地。

我相信这是最好的选择。

试试看，告诉我们它是否解决了您的记忆问题。

于 2012-02-03T09:58:00.597 回答