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 Mon, 03 Jan 2011 19:54:40 GMT
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 \

Incremental mode will take some of the sting out of large collections.

 http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

    -XX:+CMSIncrementalMode \
    -XX:+CMSIncrementalPacing \

If you hadn't disabled manual GC...

    -XX:+ExplicitGCInvokesConcurrent \

These will output a lot more info.  verbosegc is superceded by
PrintGCDetails, I think.

    -XX:+PrintGCDetails \
    -XX:+PrintGCTimeStamps \
    -XX:+PrintTenuringDistribution \
    -XX:-TraceClassUnloading \


p



> regards
> Leon
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 


Mime
View raw message