2016-02-27 96 views
-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更高的负载。请帮助我这样做。

+0

您还可以为初始和最大堆大小设置不同的值。通过这种方式,GC将定期扫描已解除引用的对象,并缩短GC周期。还配置您的jconsole检查内存泄漏! –

回答

0

基本上u的可能面临内存泄漏。使用YourKIt(或您选择的分析器),运行您的应用程序,并在适当的时间内,定期强制垃圾收集,然后检查哪些对象仍在累积,尽管强制gc。这可能是一项耗时的活动,但最终还是会付诸东流的。

可能的原因是ClassLoader的泄漏,弱引用,妥善执行缓存或其他任何东西。

0

有没有从你提供的日志摘录,可见的问题。

[时间:用户= 0.04 SYS = 0.00,实际= 0.01秒]

收集了10ms的挂钟时间。

并发标记扫代总3853568K,使用687966K [0x00000006d4cc0000,0x00000007c0000000,0x00000007c0000000)

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

虽然这只是一个年轻的根集合,所以也许你已经张贴日志的irrelvant一部分。也许是因为你认为“失败”意味着“不好”?不是这种情况。这只是年轻一代的触发器,这意味着如果没有首先收集年轻一代,分配就无法得到满足。

您可能想要通过GCViewer运行整个事情来查看您是否确实遇到GC问题。