【问题标题】:RSS/VSS are growing unstopped until all memory & swap on machine endsRSS/VSS 不断增长,直到机器上的所有内存和交换结束
【发布时间】:2010-08-18 04:41:51
【问题描述】:

我们在 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 

有没有人遇到过类似的情况?

谢谢, 盎司

【问题讨论】:

    标签: java linux memory rhel


    【解决方案1】:

    您使用的服务器的 CPU/RAM 是多少?您应该咨询RHEL compatibility matrix for WLS 9.2 并确保您的 JDK/CPU 配置是受支持的组合。此外,如果您愿意,您可能希望将 JRockit 作为您的 JVM。最后,还可以尝试降低最大堆空间(-Xmx 和 -Xms),看看服务器是否更稳定。

    【讨论】:

    • 您好,感谢您的回复。 CPU Intel(R) Xeon(R)E5540 @ 2.53GHz,RAM 48g,JDK 1.5.0.16 和配置受支持。由于我们刚刚切换到 Linux(从 HP-UX i),未来出于性能原因我们可能会检查 JRockit。谢谢,奥兹
    • 您运行的是 64 位内核吗?您是否尝试过升级到 JDK 1.5.0_22?
    【解决方案2】:

    我们在使用不同的操作系统(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... ——所以我们决定删除它。很简单。

    我相信这是最好的选择。

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

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2014-06-14
      • 2014-11-20
      • 1970-01-01
      • 2014-11-23
      • 2019-11-12
      • 2014-02-25
      • 2013-10-20
      相关资源
      最近更新 更多