logging in or signing up slides Rafael Download Post to : URL : Related Presentations : Share Add to Flag Embed Email Send to Blogs and Networks Add to Channel Uploaded from authorPOINTLite Insert YouTube videos in PowerPont slides with aS Desktop Copy embed code: (To copy code, click on the text box) Embed: URL: Thumbnail: WordPress Embed Customize Embed The presentation is successfully added In Your Favorites. Views: 146 Category: Education License: All Rights Reserved Like it (0) Dislike it (0) Added: January 03, 2008 This Presentation is Public Favorites: 0 Presentation Description No description available. Comments Posting comment... Premium member Presentation Transcript Garbage Collection: Garbage Collection Danny Angus Introduction: Introduction Student loans, amongst other things, run B2B applications implementing government policy in the UK. We process 900,000+ complex loan applications in the six months from March to September every year. 2Introduction: Introduction We have to tune performance, our funding stakeholders demand we provide value for money. (As a tax payer so do I). You should tune for performance too. 3Myth: Myth Memory management is one of the things Java is supposed to do for us. We do have to be good citizens And sometimes it still fails to live up to our expectations. 4Just take a look at these comments from APR, and imagine the code. Glad you don’t have to write it? I know I am.: Just take a look at these comments from APR, and imagine the code. Glad you don’t have to write it? I know I am. /* Round up the block size to the next boundary, but always * allocate at least a certain size (MIN_ALLOC). */ /* Find the index for this node size by * dividing its size by the boundary size */ /* First see if there are any nodes in the area we know * our node will fit into. */ /* Walk the free list to see if there are * any nodes on it of the requested size * * NOTE: an optimization would be to check * allocator->free[index] first and if no * node is present, directly use * allocator->free[max_index]. This seems * like overkill though and could cause * memory waste. */ /* If we found nothing, seek the sink (at index 0), if * it is not empty. */ /* Walk the free list to see if there are * any nodes on it of the requested size */ /* If we haven't got a suitable node, malloc a new one * and initialize it. */ 5So what do we have: So what do we have A load of theory but no silver bullet (but I think Sun would like the “AgressiveHeap” option to work for most of us) No “API” which we (the hardworking geeks in the field) can use to even hint about what our applications are going to be doing. A few general heap options A lot of “secret” knowledge 6How to keep up with the work: How to keep up with the work Suns JVM uses “generational” heap management Partions for old & young Java can create a lot of new objects, For long running processes under steady heavy load that means a real lot. 7The Generations: The Generations Young generation New space, when you create an object memory here is allocated. Tenured generation If it last longer than a wee while it is moved here Permanent generation Stuff (classes loaded mainly) that won’t be thrown away 8And there’s more to the young: And there’s more to the young Creation space Two survivor spaces Objects are promoted from survivor space when they survive a certain number of collections. You can set this number. 9A Generalisation about types: A Generalisation about types Mark and sweep Start in the VM and follow all of the object references you can reach, mark each object Remove the ones you cant reach Stop and copy Stop execution Copy all the objects you can reach into a new space 10Mark and sweep: Mark and sweep Lots of work to do all that marking Leads to fragmentation You can sweep concurrent with execution This is good if you have plenty of CPU and want to avoid pauses. Still need to defrag now and then though. More garbage == more work 11Stop and copy: Stop and copy You need twice as much memory Pauses everything for the whole time it takes De-fragments the space every time More survivors == more work 12JRE 1.4: JRE 1.4 Copying collector – default for the young space – aka “minor collection” Parallel copying –XX:+UseParNewGC Parallel scavenge –XX:+UseParallelGC Mark – compact – default for tenured space – major collection Concurrent collector –XX:+UseConcMarkSweepGC 13What is your goal?: What is your goal? “They” expect you to choose between Throughput & Response time, or speed v no pauses. But if you’re like me you’ll want everything. 14The compromise: The compromise Balance the time spent in collections against the number of collections. Get the maximum benefit from each collection. 15Some more clues: Some more clues Space fills to its threshold, and is cleaned right out. In a steady state process there will be an apparent base load in a newly cleaned space, you can measure this and size the spaces. Then you can pick the collector that least intrusively keeps up with the rate at which you use the space. 16So how do you measure?: So how do you measure? -loggc:<filepath> -XX:PrintGCDetails -verbose:gc [GC 0.000: [DefNew: 512K->64K(576K), 0.0051493 secs] 512K->155K(1984K), 0.0053630 secs] Draw the graph You’re looking for a sawtooth shape The peaks and troughs should reach the same point every time. 17Illustration: Pink is before, blue after See the small amount cleaned at each small collection And the big amount cleaned in the major collection What does this suggest? Young space is too small Time line – there is no time on this graph If the whole think took a day do we have too few major collections If this whole thing is a minute do we have too many Context is important Illustration 18If the heap in use grows: If the heap in use grows Reduce the frequency of collections by increasing the young space 19Another example: This time the young generation is more cleaned Fewer promotions Tenured space in use after the major collection If this continues the size of the heap will increase And pauses will be bigger Another example 20Tie it back to real events: Logarythmic early growth Steady young size and promotion Would we want the lines to be more horizontal? Only you can tell, balance memory use vs CPU Is this under load or is your normal peak load worse? Optimise for normal peak = = efficient Optimise for occasional peak = = robust Tie it back to real events 21If major collections are too frequent: If major collections are too frequent Increase the size of the heap a bit.. 22Don’t overdo it : Don’t overdo it If the tenured space is too big you’ll have longer pauses for the tenured collection Reduce the number of promtions by sizing the young generation. -XX:NewSize -XX:MaxNewSize -XX:SurvivorRatio 23Size the young gen: Size the young gen 24Use Subtraction… : Use Subtraction… [GC 83473.842: [DefNew: 98814K->7027K(104832K), 0.0829770 secs] 704440K->612653K(1036928K), 0.0831090 secs] [GC 83475.633: [DefNew: 100210K->3604K(104832K), 0.0963160 secs] 705836K->613349K(1036928K), 0.0964500 secs] 696k promoted. 25Time, don’t forget it: Time, don’t forget it 26A real default profile: A real default profile 27Here’s one I prepared earlier: Here’s one I prepared earlier 28Myth exploded: Myth exploded “Make –Xmx and –Xms the same size” If you have plenty of RAM make –Xmx big to cope with the unexpected But keep –Xms small to manage collection frequency and size 29Tip: Tip Never let the OS swap out the Java heap This is because marking involves traversing the whole heap in unpredictable patterns 30Size the Young generation : Size the Young generation Make those collections work for you New size, new ratio balance the eden space and the survivor spaces You want as many of your short lived objects to live and die in one collection, without letting the collection get too onerous of course 31Size the permanent space: Size the permanent space Size it just a bit bigger than you need 32Myth exploded: Myth exploded “allocations which can’t be made in permanent space will be made from tenured space” In practice a compacting collection occurs, and if it doesn’t release enough concurrent memory in the perm space the jvm spins up to 100% re-trying the compaction. 33Parallel and concurrent: Parallel and concurrent Might make sense if you have plenty of cpu Uses more cpu, but no pauses Except that you still get de-fragmentation pauses, threads have to be parked before objects can be moved and references re-written. Marking takes a while, and then you have to collect. This may be too slow to clear down during peaks. 34Aggressive heap: Aggressive heap The silver bullet? 35Some more stuff: Some more stuff -Xincgc / -Xnoincgc -XX:ParallelGCThreads=<desired number> -XX:+UseCMSCompactAtFullCollection -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=1024 -XX:SoftRefLRUPolicyMSPerMB=10000 -XX:PretenureSizeThreshold=<byte size> -XX:+DisableExplicitGC -XX:CMSInitiatingOccupancyFraction=<percent> -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSFullGCsBeforeCompaction=1 36Sizes: Sizes Xmsvalue -Xmxvalue -Xmnvalue -XX:MinHeapFreeRatio=minimum -XX:MaxHeapFreeRatio=maximum -XX:NewRatio=ratio -XX:NewSize=size -XX:MaxNewSize=size -XX:MaxPermSize=<desired size> -XX:+AggressiveHeap -XX:+UseAdaptiveSizePolicy 37Conclusion: Conclusion If you spend too much time doing this you probably need to buy hardware. But it is worth doing now and again. Thanks to Student Loans for letting me talk frankly about our problems. 38Questions?: Questions? http://people.apache.org/~danny 39 You do not have the permission to view this presentation. In order to view it, please contact the author of the presentation.
slides Rafael Download Post to : URL : Related Presentations : Share Add to Flag Embed Email Send to Blogs and Networks Add to Channel Uploaded from authorPOINTLite Insert YouTube videos in PowerPont slides with aS Desktop Copy embed code: (To copy code, click on the text box) Embed: URL: Thumbnail: WordPress Embed Customize Embed The presentation is successfully added In Your Favorites. Views: 146 Category: Education License: All Rights Reserved Like it (0) Dislike it (0) Added: January 03, 2008 This Presentation is Public Favorites: 0 Presentation Description No description available. Comments Posting comment... Premium member Presentation Transcript Garbage Collection: Garbage Collection Danny Angus Introduction: Introduction Student loans, amongst other things, run B2B applications implementing government policy in the UK. We process 900,000+ complex loan applications in the six months from March to September every year. 2Introduction: Introduction We have to tune performance, our funding stakeholders demand we provide value for money. (As a tax payer so do I). You should tune for performance too. 3Myth: Myth Memory management is one of the things Java is supposed to do for us. We do have to be good citizens And sometimes it still fails to live up to our expectations. 4Just take a look at these comments from APR, and imagine the code. Glad you don’t have to write it? I know I am.: Just take a look at these comments from APR, and imagine the code. Glad you don’t have to write it? I know I am. /* Round up the block size to the next boundary, but always * allocate at least a certain size (MIN_ALLOC). */ /* Find the index for this node size by * dividing its size by the boundary size */ /* First see if there are any nodes in the area we know * our node will fit into. */ /* Walk the free list to see if there are * any nodes on it of the requested size * * NOTE: an optimization would be to check * allocator->free[index] first and if no * node is present, directly use * allocator->free[max_index]. This seems * like overkill though and could cause * memory waste. */ /* If we found nothing, seek the sink (at index 0), if * it is not empty. */ /* Walk the free list to see if there are * any nodes on it of the requested size */ /* If we haven't got a suitable node, malloc a new one * and initialize it. */ 5So what do we have: So what do we have A load of theory but no silver bullet (but I think Sun would like the “AgressiveHeap” option to work for most of us) No “API” which we (the hardworking geeks in the field) can use to even hint about what our applications are going to be doing. A few general heap options A lot of “secret” knowledge 6How to keep up with the work: How to keep up with the work Suns JVM uses “generational” heap management Partions for old & young Java can create a lot of new objects, For long running processes under steady heavy load that means a real lot. 7The Generations: The Generations Young generation New space, when you create an object memory here is allocated. Tenured generation If it last longer than a wee while it is moved here Permanent generation Stuff (classes loaded mainly) that won’t be thrown away 8And there’s more to the young: And there’s more to the young Creation space Two survivor spaces Objects are promoted from survivor space when they survive a certain number of collections. You can set this number. 9A Generalisation about types: A Generalisation about types Mark and sweep Start in the VM and follow all of the object references you can reach, mark each object Remove the ones you cant reach Stop and copy Stop execution Copy all the objects you can reach into a new space 10Mark and sweep: Mark and sweep Lots of work to do all that marking Leads to fragmentation You can sweep concurrent with execution This is good if you have plenty of CPU and want to avoid pauses. Still need to defrag now and then though. More garbage == more work 11Stop and copy: Stop and copy You need twice as much memory Pauses everything for the whole time it takes De-fragments the space every time More survivors == more work 12JRE 1.4: JRE 1.4 Copying collector – default for the young space – aka “minor collection” Parallel copying –XX:+UseParNewGC Parallel scavenge –XX:+UseParallelGC Mark – compact – default for tenured space – major collection Concurrent collector –XX:+UseConcMarkSweepGC 13What is your goal?: What is your goal? “They” expect you to choose between Throughput & Response time, or speed v no pauses. But if you’re like me you’ll want everything. 14The compromise: The compromise Balance the time spent in collections against the number of collections. Get the maximum benefit from each collection. 15Some more clues: Some more clues Space fills to its threshold, and is cleaned right out. In a steady state process there will be an apparent base load in a newly cleaned space, you can measure this and size the spaces. Then you can pick the collector that least intrusively keeps up with the rate at which you use the space. 16So how do you measure?: So how do you measure? -loggc:<filepath> -XX:PrintGCDetails -verbose:gc [GC 0.000: [DefNew: 512K->64K(576K), 0.0051493 secs] 512K->155K(1984K), 0.0053630 secs] Draw the graph You’re looking for a sawtooth shape The peaks and troughs should reach the same point every time. 17Illustration: Pink is before, blue after See the small amount cleaned at each small collection And the big amount cleaned in the major collection What does this suggest? Young space is too small Time line – there is no time on this graph If the whole think took a day do we have too few major collections If this whole thing is a minute do we have too many Context is important Illustration 18If the heap in use grows: If the heap in use grows Reduce the frequency of collections by increasing the young space 19Another example: This time the young generation is more cleaned Fewer promotions Tenured space in use after the major collection If this continues the size of the heap will increase And pauses will be bigger Another example 20Tie it back to real events: Logarythmic early growth Steady young size and promotion Would we want the lines to be more horizontal? Only you can tell, balance memory use vs CPU Is this under load or is your normal peak load worse? Optimise for normal peak = = efficient Optimise for occasional peak = = robust Tie it back to real events 21If major collections are too frequent: If major collections are too frequent Increase the size of the heap a bit.. 22Don’t overdo it : Don’t overdo it If the tenured space is too big you’ll have longer pauses for the tenured collection Reduce the number of promtions by sizing the young generation. -XX:NewSize -XX:MaxNewSize -XX:SurvivorRatio 23Size the young gen: Size the young gen 24Use Subtraction… : Use Subtraction… [GC 83473.842: [DefNew: 98814K->7027K(104832K), 0.0829770 secs] 704440K->612653K(1036928K), 0.0831090 secs] [GC 83475.633: [DefNew: 100210K->3604K(104832K), 0.0963160 secs] 705836K->613349K(1036928K), 0.0964500 secs] 696k promoted. 25Time, don’t forget it: Time, don’t forget it 26A real default profile: A real default profile 27Here’s one I prepared earlier: Here’s one I prepared earlier 28Myth exploded: Myth exploded “Make –Xmx and –Xms the same size” If you have plenty of RAM make –Xmx big to cope with the unexpected But keep –Xms small to manage collection frequency and size 29Tip: Tip Never let the OS swap out the Java heap This is because marking involves traversing the whole heap in unpredictable patterns 30Size the Young generation : Size the Young generation Make those collections work for you New size, new ratio balance the eden space and the survivor spaces You want as many of your short lived objects to live and die in one collection, without letting the collection get too onerous of course 31Size the permanent space: Size the permanent space Size it just a bit bigger than you need 32Myth exploded: Myth exploded “allocations which can’t be made in permanent space will be made from tenured space” In practice a compacting collection occurs, and if it doesn’t release enough concurrent memory in the perm space the jvm spins up to 100% re-trying the compaction. 33Parallel and concurrent: Parallel and concurrent Might make sense if you have plenty of cpu Uses more cpu, but no pauses Except that you still get de-fragmentation pauses, threads have to be parked before objects can be moved and references re-written. Marking takes a while, and then you have to collect. This may be too slow to clear down during peaks. 34Aggressive heap: Aggressive heap The silver bullet? 35Some more stuff: Some more stuff -Xincgc / -Xnoincgc -XX:ParallelGCThreads=<desired number> -XX:+UseCMSCompactAtFullCollection -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=1024 -XX:SoftRefLRUPolicyMSPerMB=10000 -XX:PretenureSizeThreshold=<byte size> -XX:+DisableExplicitGC -XX:CMSInitiatingOccupancyFraction=<percent> -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSFullGCsBeforeCompaction=1 36Sizes: Sizes Xmsvalue -Xmxvalue -Xmnvalue -XX:MinHeapFreeRatio=minimum -XX:MaxHeapFreeRatio=maximum -XX:NewRatio=ratio -XX:NewSize=size -XX:MaxNewSize=size -XX:MaxPermSize=<desired size> -XX:+AggressiveHeap -XX:+UseAdaptiveSizePolicy 37Conclusion: Conclusion If you spend too much time doing this you probably need to buy hardware. But it is worth doing now and again. Thanks to Student Loans for letting me talk frankly about our problems. 38Questions?: Questions? http://people.apache.org/~danny 39