Java垃圾收集分配失敗

-1

我運行有8GB內存和4個CPU的機器上我的Java應用程序。但對於壓力測試較長時間運行的應用程序後，觀察到垃圾回收問題，因爲內存是完全充分，似乎GC週期要長的時間才能完成，但我無法找出可能的原因及其解決方法。我們要求完成的平均等待時間沒有太大差異。但它不能同時服務多線程。Java垃圾收集分配失敗

的內存填充

{Heap before GC invocations=193901 (full 4): 
par new generation total 306688K, used 274312K [0x00000006c0000000, 0x00000006d4cc0000, 0x00000006d4cc0000) 
    eden space 272640K, 100% used [0x00000006c0000000, 0x00000006d0a40000, 0x00000006d0a40000) 
    from space 34048K, 4% used [0x00000006d2b80000, 0x00000006d2d222c8, 0x00000006d4cc0000) 
    to space 34048K, 0% used [0x00000006d0a40000, 0x00000006d0a40000, 0x00000006d2b80000) 
concurrent mark-sweep generation total 3853568K, used 687930K [0x00000006d4cc0000, 0x00000007c0000000, 0x00000007c0000000) 
Metaspace  used 58528K, capacity 59902K, committed 61732K, reserved 1103872K 
    class space used 6866K, capacity 7109K, committed 7464K, reserved 1048576K 
89974.407: [GC (Allocation Failure) 89974.407: [ParNew: 274312K->1655K(306688K), 0.0101861 secs] 962243K->689622K(4160256K), 0.0104010 secs] [Times: user=0.04 sys=0.00, real=0.01 secs] 
Heap after GC invocations=193902 (full 4): 
par new generation total 306688K, used 1655K [0x00000006c0000000, 0x00000006d4cc0000, 0x00000006d4cc0000) 
    eden space 272640K, 0% used [0x00000006c0000000, 0x00000006c0000000, 0x00000006d0a40000) 
    from space 34048K, 4% used [0x00000006d0a40000, 0x00000006d0bdded0, 0x00000006d2b80000) 
    to space 34048K, 0% used [0x00000006d2b80000, 0x00000006d2b80000, 0x00000006d4cc0000) 
concurrent mark-sweep generation total 3853568K, used 687966K [0x00000006d4cc0000, 0x00000007c0000000, 0x00000007c0000000) 
Metaspace  used 58528K, capacity 59902K, committed 61732K, reserved 1103872K 
    class space used 6866K, capacity 7109K, committed 7464K, reserved 1048576K 
} 
89974.418: Total time for which application threads were stopped: 0.0127352 seconds 
89974.988: Application time: 0.5703336 seconds

我想來就結束之後

top - 11:24:03 up 44 days, 23:45, 1 user, load average: 0.39, 0.47, 0.65 
Tasks: 158 total, 1 running, 157 sleeping, 0 stopped, 0 zombie 
Cpu(s): 18.8%us, 2.1%sy, 0.0%ni, 64.2%id, 12.9%wa, 0.2%hi, 1.8%si, 0.0%st 
Mem: 7672012k total, 7270396k used, 401616k free, 238468k buffers 
Swap: 5238776k total, 34584k used, 5204192k free, 2390820k cached 

    PID USER  PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND                   
15811 root  20 0 7919m 4.1g 9m S 101.1 55.9 4134:37 java

樣品GC日誌我開始我的應用程序有以下PARAMS

-Xms4096M -Xmx4096M 
-XX:MaxPermSize=512M 
-XX:PermSize=512m 
-XX:+UseConcMarkSweepGC 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCDetails 
-XX:+PrintGCApplicationStoppedTime 
-XX:+PrintGCApplicationConcurrentTime 
-XX:+PrintHeapAtGC 
-Xloggc:/root/tomcat_logs/gc_logs.log

輸出top命令爲什麼記憶力充足，我能做些什麼來克服它，以便我可以運行我的應用程序l更高的負載。請幫助我這樣做。

來源

2016-02-27 Himanshu Goel

您還可以爲初始和最大堆大小設置不同的值。通過這種方式，GC將定期掃描已解除引用的對象，並縮短GC週期。還配置您的jconsole檢查內存泄漏！ –

基本上u的可能面臨內存泄漏。使用YourKIt（或您選擇的分析器），運行您的應用程序，並在適當的時間內，定期強制垃圾收集，然後檢查哪些對象仍在累積，儘管強制gc。這可能是一項耗時的活動，但最終還是會付諸東流的。

可能的原因是ClassLoader的泄漏，弱引用，妥善執行緩存或其他任何東西。

來源

2016-02-27 06:06:11 Anil

有沒有從你提供的日誌摘錄，可見的問題。

[時間：用戶= 0.04 SYS = 0.00，實際= 0.01秒]

收集了10ms的掛鐘時間。

併發標記掃代總3853568K，使用687966K [0x00000006d4cc0000，0x00000007c0000000，0x00000007c0000000）

老一代只有680MB/3.8G充分。

雖然這只是一個年輕的根集合，所以也許你已經張貼日誌的irrelvant一部分。也許是因爲你認爲「失敗」意味着「不好」？不是這種情況。這只是年輕一代的觸發器，這意味着如果沒有首先收集年輕一代，分配就無法得到滿足。

您可能想要通過GCViewer運行整個事情來查看您是否確實遇到GC問題。

來源

2016-02-27 06:30:35 the8472

Java垃圾收集分配失敗

回答

相關問題