On 1/3/11 2:41 PM, Leon Rosenberg wrote: > On Mon, Jan 3, 2011 at 3:10 PM, Pid <p...@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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
0x62590808.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
