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
