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 <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 \
Having said that, you might also just try, instead: -XX:+UseParallelGC -XX:+UseAdaptiveSizePolicy p
0x62590808.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
