2014-07-12 136 views
0

我一個JBoss 7.1.1最終服務器上乳寧的應用,部署在完成RedHat 5垃圾收集器釋放內存造成全GC

當我啓動服務器,使用的內存每次啓動GC後都會增加2.5M,導致在1或2小時內發生完全GC錯誤。

即使未使用該應用程序,也會發生這種情況。無論gcInterval參數如何,GC都會每10秒運行一次。

部署在具有相同JVM和JVM參數的windows開發PC上的相同應用程序正在運行完美。如果未使用應用程序,則GC不會啓動。 GC工作後使用的內存不會增加。

JDK:1.7.0_55 64 JVM ARGS:-Xms256m -Xmx1024m -XX:MaxPermSize參數=512米-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同一應用程序的虛擬機屏幕截圖,Windows下的開發PC上的相同JVM和JVM參數。左側:未使用的應用程序,正在使用的正確應用程序。 GC正確functionning,運行必要時,可以使用的內存量是穩定的:

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

謝謝您的幫助!

編輯:這裏是詳細GC日誌:

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:存儲器轉儲揭示了內存泄漏的來源:「com.arjuna.ats.internal.jta的

3 616實例.transaction.arjunacore.TransactionImple「,由」org.jboss.modules.ModuleClassLoader @ 0x78122a170「加載佔用153 506 944(64,98%)字節。這些實例是從一個「java.util.HashMap $ Entry []」實例引用的,由「」加載「」

回答

0

找出解決方案......這是通過在模塊ironjacamar在JBoss中的錯誤AS 7.1.1 Final版...

要糾正,你可以打補丁造成的這一個模塊:ironjacamar-core-impl.jar

或更新的JBoss AS到版本7.2.0 +(你必須建立在你自己的,因爲它不再分發)

另一種選擇是切換至J老闆EAP 6.3,如果你可以適應許可證。

希望這會有所幫助:)

+0

加載,因此它正在生成額外的java對象? – rogerdpack

0

啊,我看到你有一個臭名昭着的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

+0

謝謝你的回答。事實上,問題是數據庫事務中的內存泄漏,如內存轉儲中所示:3個「com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple」實例,由「org.jboss.modules.ModuleClassLoader」加載@ 0x78122a170「佔用153 506 944(64,98%)字節。這些實例是從「java.util.HashMap $ Entry []」的一個實例中引用的,由「<系統類加載器>」 – Ben