Question

我在JBoss 7.1.1最终服务器上运行一个应用程序，部署在Linux RedHat 5

上

当我启动服务器时，每次启动GC后使用的内存都会增加2.5M，导致在1或2小时内出现完整的GC错误。

即使不使用应用程序，也会发生这种情况。无论gcInterval参数如何，GC每10秒运行一次。

在具有相同JVM和JVM args的Windows开发PC上部署的相同应用程序正在完美运行。如果未使用应用程序，则GC不会启动。 GC工作后，使用的内存不会增加。

JDK：1.7.0_55 x64 JVM args：-Xms256m -Xmx1024m -XX：MaxPermSize = 512m -verbose：gc -Dsun.rmi.dgc.client.gcInterval = 3600000 -Dsun.rmi.dgc.server.gcInterval = 3600000

[... Starting JBoss, application is not in use]
[GC 487573K->211517K(585216K), 0,0631790 secs]
[GC 490557K->213509K(585216K), 0,0636420 secs]
[... 10 minutes later]
[GC 585797K->298581K(590848K), 0,0633730 secs]
[GC 587861K->300629K(590848K), 0,0826110 secs]
[Full GC 300629K->255804K(742912K), 1,8318540 secs]
[GC 545084K->258220K(733696K), 0,0096510 secs]
[GC 538284K->260140K(708096K), 0,0139590 secs]
[... 10 minutes later]
[GC 921600K->636408K(967680K), 0,0704860 secs]
[GC 923640K->638440K(967680K), 0,1334640 secs]
[GC 925672K->640472K(967680K), 0,0706450 secs]

我已经分析了一个内存转储并用MAT打开它，而且消耗大量的对象来自JBoss，而不是来自应用程序：

（http://img4.hostingpics.net/pics/459885MAT.jpg）

比较，这是一个相同应用程序的Visual VM屏幕截图，同一个JVM和JVM args在windows下的developpement PC上。在左侧：未使用的应用程序，在正在使用的正确应用程序中。 GC正常运行，必要时运行，并且使用的内存量稳定：

（http://img4.hostingpics.net/pics/246156VisualVM.jpg）

感谢您的帮助！

编辑：这里有详细的gc log：

294,409: [GC [PSYoungGen: 131584K->10012K(236544K)] 282316K->160745K(525312K), 0,0257640 secs] [Times: user=0,05 sys=0,00, real=0,03 secs]
300,698: [GC [PSYoungGen: 145692K->13937K(240640K)] 296425K->164670K(529408K), 0,0314710 secs] [Times: user=0,06 sys=0,00, real=0,03 secs]
320,822: [GC [PSYoungGen: 149617K->26904K(234496K)] 300350K->177637K(523264K), 0,0596520 secs] [Times: user=0,11 sys=0,00, real=0,06 secs]
349,830: [GC [PSYoungGen: 167704K->36648K(240128K)] 318437K->187381K(528896K), 0,0856060 secs] [Times: user=0,14 sys=0,00, real=0,09 secs]
400,827: [GC [PSYoungGen: 177448K->50600K(237056K)] 328181K->201333K(525824K), 0,1015110 secs] [Times: user=0,20 sys=0,00, real=0,10 secs]
453,335: [GC [PSYoungGen: 197544K->65128K(239616K)] 348277K->215861K(528384K), 0,1270900 secs] [Times: user=0,24 sys=0,00, real=0,13 secs]
507,227: [GC [PSYoungGen: 212072K->79720K(235520K)] 362805K->230453K(524288K), 0,1589030 secs] [Times: user=0,31 sys=0,00, real=0,16 secs]
557,260: [GC [PSYoungGen: 218472K->93288K(232448K)] 369205K->244021K(521216K), 0,1785030 secs] [Times: user=0,35 sys=0,00, real=0,18 secs]
608,082: [GC [PSYoungGen: 232040K->106920K(233472K)] 382773K->257653K(522240K), 0,2963930 secs] [Times: user=0,40 sys=0,00, real=0,29 secs]
650,849: [GC [PSYoungGen: 224168K->110152K(233472K)] 374901K->268963K(522240K), 0,2341450 secs] [Times: user=0,45 sys=0,00, real=0,23 secs]
693,327: [GC [PSYoungGen: 227400K->103792K(233472K)] 386211K->280538K(522240K), 0,2343350 secs] [Times: user=0,46 sys=0,01, real=0,23 secs]
736,396: [GC [PSYoungGen: 221040K->91616K(233472K)] 397786K->292164K(522240K), 0,2261210 secs] [Times: user=0,43 sys=0,02, real=0,23 secs]
778,381: [GC [PSYoungGen: 208864K->74208K(233472K)] 409412K->303868K(522240K), 0,2123170 secs] [Times: user=0,39 sys=0,03, real=0,21 secs]
821,401: [GC [PSYoungGen: 191456K->58592K(233472K)] 421116K->315572K(522240K), 0,1734580 secs] [Times: user=0,32 sys=0,02, real=0,18 secs]
821,575: [Full GC [PSYoungGen: 58592K->18031K(233472K)] [ParOldGen: 256980K->288398K(480768K)] 315572K->306430K(714240K) [PSPermGen: 79966K->79787K(139776K)], 2,7505260 secs] [Times: user=5,14 sys=0,01, real=2,75 secs]
863,389: [GC [PSYoungGen: 135279K->23424K(233472K)] 423678K->318334K(714240K), 0,2504760 secs] [Times: user=0,49 sys=0,00, real=0,25 secs]
906,570: [GC [PSYoungGen: 140672K->24256K(233472K)] 435582K->330022K(714240K), 0,0820190 secs] [Times: user=0,15 sys=0,01, real=0,08 secs]
948,403: [GC [PSYoungGen: 141504K->24192K(233472K)] 447270K->341774K(714240K), 0,0817190 secs] [Times: user=0,15 sys=0,01, real=0,08 secs]
991,577: [GC [PSYoungGen: 141440K->12576K(233472K)] 459022K->353598K(714240K), 0,0888270 secs] [Times: user=0,16 sys=0,01, real=0,09 secs]
1032,722: [GC [PSYoungGen: 129824K->12192K(233472K)] 470846K->365022K(714240K), 0,0605500 secs] [Times: user=0,10 sys=0,01, real=0,06 secs]
Heap
 PSYoungGen      total 233472K, used 46338K [0x00000000eaa80000, 0x0000000100000000, 0x0000000100000000)
  eden space 117248K, 29% used [0x00000000eaa80000,0x00000000ecbd8be8,0x00000000f1d00000)
  from space 116224K, 10% used [0x00000000f8e80000,0x00000000f9a68000,0x0000000100000000)
  to   space 116224K, 0% used [0x00000000f1d00000,0x00000000f1d00000,0x00000000f8e80000)
 ParOldGen       total 480768K, used 352830K [0x00000000c0000000, 0x00000000dd580000, 0x00000000eaa80000)
  object space 480768K, 73% used [0x00000000c0000000,0x00000000d588fad8,0x00000000dd580000)
 PSPermGen       total 139776K, used 80224K [0x00000000a0000000, 0x00000000a8880000, 0x00000000c0000000)
  object space 139776K, 57% used [0x00000000a0000000,0x00000000a4e58260,0x00000000a8880000)

Edit2：内存转储显示内存泄漏的来源：

＆＃34; com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple＆＃34;的3 616个实例，由＆＃34; org.jboss.modules.ModuleClassLoader @ 0x78122a170＆＃34;加载占用153 506 944（64,98％）个字节。这些实例是从＆＃34; java.util.HashMap $ Entry []＆＃34;的一个实例引用的，由＆＃34;＆＃34;

加载

Answer 1

啊，我看到你有一个臭名昭着的JRE堆查询。你不喜欢这些类型的问题吗？！？！ ^ _ ^

很难回答你没有更多信息的问题，就像Arunkumar所说的那样。但是我的回答可以很一般。通常在设置JRE堆配置时，应该在Wrapper.conf文件中完成。在这里，您应该指定GC方法，限制，页面大小等。仅出于演示目的，请参阅下面的示例;

wrapper.java.additional.4=-XX:SurvivorRatio=6
wrapper.java.additional.5=-XX:MaxPermSize=320m
wrapper.java.additional.6=-Xss256k
wrapper.java.additional.7=-XX:+UseConcMarkSweepGC
wrapper.java.additional.8=-XX:+UseParNewGC
wrapper.java.additional.9=-XX:TargetSurvivorRatio=90
wrapper.java.additional.10=-XX:MaxTenuringThreshold=31
wrapper.java.additional.11=-XX:LargePageSizeInBytes=4m
#wrapper.java.additional.12=-XX:+UseLargePages
#Make sure that the RMI garbage collection is done every hour, not every minute
wrapper.java.additional.12=-Dsun.rmi.dgc.client.gcInterval=3600000 
wrapper.java.additional.13=-Dsun.rmi.dgc.server.gcInterval=3600000
wrapper.java.additional.14=-XX:NewSize=836m
wrapper.java.additional.15=-XX:MaxNewSize=836m

Oracle网站上有很多关于Java调优的文档，这个链接可能会有所帮助。

http://docs.oracle.com/cd/E15523_01/web.1111/e13814/jvm_tuning.htm

我希望这有助于您的查询。

此致 Vect0r

Answer 2

找出解决方案......这是由JBoss AS 7.1.1版本中的模块ironjacamar中的错误引起的......

要更正，您可以使用以下方法修补模块：ironjacamar-core-impl.jar

或将JBoss更新为AS版本7.2.0 +（您必须自行构建，因为它不再分发）

如果您可以使用许可证，则可以选择切换到JBoss EAP 6.3。

希望这会有所帮助：）

垃圾收集器无法在JBoss 7.1.1上释放内存导致Full GC

2 个答案: