[GC 524288K->103751K(2009792K), 0.1105872 secs] [GC 628039K->105751K(2009792K), 0.0925628 secs] [GC 630039K->109023K(2009792K), 0.0702017 secs] [GC 633311K->115263K(2009792K), 0.0766341 secs] [GC 639551K->117723K(2009792K), 0.0731049 secs] [GC 642011K->120195K(1980096K), 0.0755788 secs] [GC 614787K->122572K(1908352K), 0.1118307 secs] [GC 617164K->118300K(1957184K), 0.0198061 secs] [GC 559388K->124316K(1849472K), 0.0162145 secs] [GC 565404K->130372K(1958400K), 0.0239592 secs] [GC 556356K->136556K(1830208K), 0.0294408 secs] [GC 562540K->142740K(1958976K), 0.0202257 secs] [GC 565396K->148924K(1958976K), 0.0194222 secs] [GC 571580K->155092K(1962624K), 0.0195487 secs] [GC 582676K->170156K(1960256K), 0.0393426 secs] [GC 597740K->215084K(1974144K), 0.1229404 secs] [GC 661292K->221300K(1967360K), 0.1056735 secs] [GC 667508K->227388K(1979968K), 0.0218560 secs] [GC 688828K->233660K(1976768K), 0.0225914 secs] [GC 695100K->240100K(1987904K), 0.0225009 secs] [GC 716452K->246716K(1983744K), 0.0227506 secs] [GC 723068K->253428K(1996928K), 0.0226864 secs] [GC 747444K->305836K(1992384K), 0.1136048 secs] [GC 799852K->312556K(1998144K), 0.1169098 secs] [GC 809452K->318924K(1994048K), 0.0234625 secs] [GC 815820K->325316K(2006784K), 0.0230104 secs] [GC 839236K->331916K(2002432K), 0.1496760 secs] [GC 845836K->338572K(2015488K), 0.0233363 secs] [GC 869900K->345436K(2011136K), 0.0268697 secs]
For 30 second worth of calculations, this doesn't look to bad to me. I increased the heap space a lot, but I'm just bordering on the edge of my real memory, so it's not helping much. Enabling the -server thing seemed to help a tinny bit though. On Nov 6, 12:32 pm, Peter Schuller <peter.schul...@infidyne.com> wrote: > > You can use Visual VM (https://visualvm.dev.java.net/) to see how the > > VM is using memory. I don't think it specifically show a log of GC > > activity, but it is pretty clear from the graphs. > > Or just use -XX:+PrintGC and maybe -XX:+PrintGCDetails and > -XX:+PrintGCTimeStamps. > > I haven't checked what the code is doing, but if you suspect extremely > poor performance due to GC it may be because your application happens > to require some amount of memory that is below but fairly close to the > default maximum heap size. That may easily cause very frequent GC:s > and show up as poor performance. If this is the case, doubling the > heap size should fix it (-Xmx...). > > (The JVM does throw OutOfMemoryExceptions when it decides there is > cause too, but it is a difficult heuristic to decide when that is > actually the right thing to do. So it's very possible to be in > situations that are not quite so bad in terms of time spent doing GC > that the JVM throws an exception, yet bad enough to cause very > frequent full GC:s at considerable cost in CPU time.) > > -- > / Peter Schuller -- 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
