For those deploying to Oracle Java 7, an updated GC reference (including valid combinations) is available at http://www.fasterj.com/articles/oraclecollectors1.shtml.
Regards Edward On Tuesday, July 3, 2012 5:48:15 AM UTC-4, Niels van Klaveren wrote: > > I haven't got much experience with large scale Clojure environments, but I > do know something from managing a lot of JVM production environments. The > biggest lesson is: All applications behave differently, usually more so in > type of application than JVM language used. No hard and fast rules can be > given, monitoring and tweaking GC under representative load is usually > necessary. > > Basically, most settings you see in the article are pretty much obsolete. > To start off with a new application, there's usually two issues you need > to ask yourself: > > 1) Can the application be deployed multicore ? > 2) How important is user interaction ? > > With a bit of luck, you don't need to worry about the amount of cores > nowadays. That means in the Young Generation you use the ParNewGC (default > in JVM 6 & 7). If cores are limited (especially single-core) it might be > necessary to dip into the obsolete settings. > > If you need the application to do a job from start to finish fastest (f.i. > calculations), with as little overhead in GC, but can tolerate a lot of > pauses, then you can use the default GC (MarkSweepCompact). You could use > ConcurrentMarkSweep as well, since on multicore machines this can > outperform MSC, and usually is pretty much on par with it. The only > exception for using MSC is when the CPU load maxes out while there's enough > memory available (because if memory maxes out, the CPU load from GC) > > If you need user interaction to be as smooth as possible (f.i. webservers > / webservices), use ConcurrentMarkSweep. CMS falls back to MSC when the Old > Generation gets too fragmented for large Young Generation objects to be > promoted into it, causing a full GC because the heap needs to get compacted. > > In theory, if this situation arises, the G1 GC collector would be a better > choice, because it incrementally compacts the heap. However, in a LOT of > applications I've seen CMS behave better pause-wise than G1, so I wouldn't > start off with it. > > To monitor GC performance, use the JVM parameters: > -Xloggc:./gclog.txt > -XX:+PrintGCDetails > > This will write a log with GC information from the start of the JVM, which > can be parsed with several tools like > HPJmeter<https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPJMETER>or > > GCviewer <https://github.com/chewiebug/GCViewer>. After seeing how GC > behaves in your application under load, you can start tweaking. Other > useful links for GC info: > > Gil Tene's (Azul) presentation on Java VM Garbage Collection > <http://www.infoq.com/presentations/Understanding-Java-Garbage-Collection> > Alexey Ragozin's GC parameter > reference<http://blog.ragozin.info/2011/09/hotspot-jvm-garbage-collection-options.html>page > (including PDF) > > Regards, > > Niels > > On Monday, July 2, 2012 12:19:35 AM UTC+2, Bruce Durling wrote: >> >> Clojurians, >> >> Interesting post here on different GC settings for Java 7. Does anyone >> have any tips/experience about what settings have worked best for them >> with clojure and under what circumstances? >> >> http://www.fasterj.com/articles/oraclecollectors1.shtml >> >> cheers, >> Bruce >> >> -- >> @otfrom | CTO & co-founder @MastodonC | mastodonc.com >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
