I did use the word "mitigate" :) secondly yes you can almost prevent it with the concurrent collector. The concurrent collector will not stop-the-world unless it can not keep up or due to not-enough-contiguous free space.
So the simple example would be : 1) your application uses at most 64 megs of ram actively maximum 2) allocation 4096 megs of ram to the old-gen 3) set your CMSInitiatingOccupancyFraction to something like 50% so the majority of the time with 50% initiation will prevent any stop-the-world as it will have 2048 megs of ram worth of time to collect "something" before you want more. in the worst case scenerio of fragmentation, you will use 1 meg of ram spaced out at 63 meg intervals and your new thread wants 64megs contiguous, but that's why I allocated 4096 (64*64) due to the sheer number, you can not cause a contiguous problem now. Ignoring some anomalies and glossing over of things (like memory usage of 1 byte spaced at 63 meg intervals....) I think you can effectively in the real world avoid almost all stop-the-world gc's with the above. I have actually had to do this on tomcat servers in the past where it would do about 2 stop-the-world gc's per day. They were serving hundreds of requests per second so we had to, any long gc pause would backlog the http requests and the system would fail with in 30 seconds of the pause. On Tue, Dec 20, 2011 at 11:27 AM, Stephen Connolly < [email protected]> wrote: > On 20 December 2011 00:01, Ted <[email protected]> wrote: > > use the concurrent garbace collector can mitigate stop-the-world, you can > > configure where the concurrent process starts so most of the time stop > the > > world never actually takes place. > > NOTHING you can do will prevent the major stop the world compaction... > it is coming if you run for long enough... > > All you can do is postpone it... > > depending on your workload and allocation rate and type, you might be > postponing it longer than the next time you need to restart the app... > but it will come eventually if you let your app run for long enough. > > http://aragozin.blogspot.com/2011/12/garbage-collection-in-hotspot-jvm.html > > http://www.infoq.com/presentations/Understanding-Java-Garbage-Collection > > > > > But, back to the original problem of exporting, you may wish to stream > the > > data instead of reading it all into memory for export... then it'd > require > > no more ram than would be required for 1 record at a time (plus a list of > > the id's which should be very little ram too). > > AKA re-design the app. > > > > > > > On Tue, Dec 20, 2011 at 7:11 AM, Stephen Connolly < > > [email protected]> wrote: > > > >> if the server us dedicated and has 8gb of ram... you could give 6gb (or > 3g > >> if a 32bit os as more will nor be used on 32bit os)... BUT when the stop > >> the world big Garbage Collection triggers (and it will trigger > eventually > >> as the last resort to resolve heap fragmentation) then that gc will be 6 > >> times longer... if your app response time is important then giving more > >> memory could cause more of a problem. > >> > >> - Stephen > >> > >> --- > >> Sent from my Android phone, so random spelling mistakes, random nonsense > >> words and other nonsense are a direct result of using swype to type on > the > >> screen > >> On 19 Dec 2011 20:01, "Jim May" <[email protected]> wrote: > >> > >> > I have been doing some research on this topic and I know that there is > >> > quite a bit of information out there. Unfortunately, I usually do not > >> > notice articles that recommend JVM tuning setting for servers with X > >> amount > >> > of memory. I have an issue with a production tomcat server that is > >> running > >> > two applications. One of the applications has an export all records > >> feature > >> > AS AN OPTION. The default is export only the 100 rows on the page, but > >> > sometimes the Admin needs to go to the site and export all records > into > >> > excel for their reporting. Now the admin is triggering the export all > >> > feature and the server is imploding with out of memory errors for the > >> heap. > >> > > >> > This is the current settings: > >> > > >> > -Xms256m -Xmx1024m -XX:MaxPermSize=384m -XX:PermSize=256m > >> > > >> > I was wondering what you would recommend for JVM tuning settings on a > >> > server that has 8GB or higher of memory? Are there rules that are > usually > >> > followed in deciding the settings? The server is completely dedicated > to > >> > the two websites and the database runs on a different server. > >> > > >> > Thanks, > >> > -- > >> > James > >> > > >> > > > > > > > > -- > > Ted. > -- Ted.
