tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <...@pidster.com>
Subject Re: What is the healthy interval length for young gc?
Date Tue, 04 Jan 2011 12:08:30 GMT
On 1/3/11 7:54 PM, Pid wrote:
> On 1/3/11 2:41 PM, Leon Rosenberg wrote:
>> On Mon, Jan 3, 2011 at 3:10 PM, Pid <pid@pidster.com> wrote:
>>> On 1/3/11 1:10 PM, Leon Rosenberg wrote:
>>>> Actually no, in my understanding both are independent. I mean the gc
>>>> doesn't start "to copy over" if young is full, it simply cleans young.
>>>> However,
>>>> to quote your article: "Old generation objects are objects that
>>>> survived a few collections in the young generation area", and if
>>>> objects managed to survive longer as they should in the young space,
>>>> they might have been copied to old gen, despite the fact, that they
>>>> are young generation objects by nature (meaning short lifetime). This
>>>> theory is what I'm trying to check.
>>>
>>> Objects which survive collections in young generations will make their
>>> way into the old generation, and then sit around for a long time waiting
>>> to be collected.
>>
>> Hello pid-ster,
>>
>>
>>>
>>> What are your memory settings currently and how are the generations divided?
>>
>> -Xmx12G
>> -Xms12G
>> -XX:PermSize=128M
>> -XX:MaxPermSize=256M
>> -XX:+DisableExplicitGC
>> -verbose:GC
>> -XX:+PrintGCDetails
>> -XX:+PrintGCDateStamps
>> -Xloggc:/.../tomcat/logs/gc_tomcat.log
>>
>> jmap says:
>>
>> Attaching to process ID 16969, please wait...
>> Debugger attached successfully.
>> Server compiler detected.
>> JVM version is 14.2-b01
>>
>> using thread-local object allocation.
>> Parallel GC with 6 thread(s)
>>
>> Heap Configuration:
>>    MinHeapFreeRatio = 40
>>    MaxHeapFreeRatio = 70
>>    MaxHeapSize      = 12884901888 (12288.0MB)
>>    NewSize          = 2686976 (2.5625MB)
>>    MaxNewSize       = 17592186044415 MB
>>    OldSize          = 5439488 (5.1875MB)
>>    NewRatio         = 2
>>    SurvivorRatio    = 8
>>    PermSize         = 134217728 (128.0MB)
>>    MaxPermSize      = 268435456 (256.0MB)
>>
>> Heap Usage:
>> PS Young Generation
>> Eden Space:
>>    capacity = 4074897408 (3886.125MB)
>>
>>    used     = 1509410704 (1439.4862213134766MB)
>>    free     = 2565486704 (2446.6387786865234MB)
>>    37.04168603206219% used
>> From Space:
>>    capacity = 110755840 (105.625MB)
>>    used     = 47330080 (45.137481689453125MB)
>>    free     = 63425760 (60.487518310546875MB)
>>    42.73371047522189% used
>> To Space:
>>    capacity = 109314048 (104.25MB)
>>    used     = 0 (0.0MB)
>>    free     = 109314048 (104.25MB)
>>    0.0% used
>> PS Old Generation
>>    capacity = 8589934592 (8192.0MB)
>>    used     = 6636110912 (6328.688537597656MB)
>>    free     = 1953823680 (1863.3114624023438MB)
>>    77.25449874997139% used
>> PS Perm Generation
>>    capacity = 268435456 (256.0MB)
>>    used     = 228667664 (218.07447814941406MB)
>>    free     = 39767792 (37.92552185058594MB)
>>    85.18534302711487% used
> 
> Have you attempted to profile the heap to see what's making it into the
> old gen?  (I say attempted because 16G is a lot of heap to profile...)
> 
>>> How many processors do you have available and are you using CMS &
>>> incremental mode?
>>
>> vm with 6 assigned cores and no to both.
> 
> Deliberate choice, or just not tried it yet?  If you've got multiple
> cores parallel gc is a good idea.
> 
> Try something like this:
> 
>     -XX:+UseParNewGC \
>     -XX:+UseConcMarkSweepGC \
>     -XX:+CMSClassUnloadingEnabled \

Having said that, you might also just try, instead:

 -XX:+UseParallelGC
 -XX:+UseAdaptiveSizePolicy


p

Mime
View raw message