Re: which GC optimizations work better with Clojure?
I should mention here that if you are tuning the GC anywhere except at the end of your development cycle you're probably doing it wrong. 99% of the time you'll get better performance by reviewing your algorithms, running a CPU profiler, generating less garbage (via transients or something like that), or adding some missing type hints. You can spend a ton of time in GC optimization, but I've never seen yield huge results. Maybe 10% here or there, but I normally get orders of magnitude performance increases spending just a few hours with a CPU profiler. So it's one of those things where "if you don't know if you should change a GC setting form the default, you probably don't". On Sat, Apr 30, 2016 at 12:44 PM, Nando Breiterwrote: > I've found Censum by jClarity to be an excellent tool to tune JVM GC > parameters to your specific application running on a particular server. You > add a few GC parameters to enable logging that the tool needs, run your app > under load for enough time to get sufficient data, and then feed the log > directly into Censum, which analyzes it and then suggests improvements that > can be made to your GC parameters. There is also a list where you can ask > questions about the analysis and its suggestions and get in depth replies > from people who have extensive experience tuning JVMs. > > https://www.jclarity.com/censum/ > > > > Aria Media Sagl > +41 (0)76 303 4477 cell > skype: ariamedia > > On Sat, Apr 30, 2016 at 11:50 AM, Niels van Klaveren < > niels.vanklave...@gmail.com> wrote: > >> GC parameters used by a lot of projects are handed down like traditions >> for years, even spreading to others. They're almost never re-evaluated, >> which means they might actually lose out on new performance improvements, >> or worse, might even cause performance regressions. >> >> Most parameters in the Overtone lib for instance have been the default >> for quite some time (ParNew GC, TLAB). Where restricting New Gen might be a >> good idea to reduce new gen GC latency, it can cause unwanted promotions, >> longer tenured GC's and in the end heap fragmentation resulting in a full >> defrag gc that can take 10s of seconds. >> >> Defaults are there for a reason, to take care of most situations. Any >> settings other than the three default Garbage Collectors (Default for >> shortest time to finish, CMS for shortest pause , G1 for short pauses but >> long running times) and at most a pause hint for their heuristics means >> you're entering case-specific territory and should be treating it so. >> >> This means realistic benchmarking, profiling and comparisons between >> different settings. I'd treat any JVM product or library with more than 2 >> GC parameters with care, because if they need so much tweaking as their >> default, you can be sure to need both a good understanding of their inner >> workings and JVM memory managent as well to keep them performing in your >> specific case. >> >> -- >> 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 >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > 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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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
Re: which GC optimizations work better with Clojure?
I've found Censum by jClarity to be an excellent tool to tune JVM GC parameters to your specific application running on a particular server. You add a few GC parameters to enable logging that the tool needs, run your app under load for enough time to get sufficient data, and then feed the log directly into Censum, which analyzes it and then suggests improvements that can be made to your GC parameters. There is also a list where you can ask questions about the analysis and its suggestions and get in depth replies from people who have extensive experience tuning JVMs. https://www.jclarity.com/censum/ Aria Media Sagl +41 (0)76 303 4477 cell skype: ariamedia On Sat, Apr 30, 2016 at 11:50 AM, Niels van Klaveren < niels.vanklave...@gmail.com> wrote: > GC parameters used by a lot of projects are handed down like traditions > for years, even spreading to others. They're almost never re-evaluated, > which means they might actually lose out on new performance improvements, > or worse, might even cause performance regressions. > > Most parameters in the Overtone lib for instance have been the default for > quite some time (ParNew GC, TLAB). Where restricting New Gen might be a > good idea to reduce new gen GC latency, it can cause unwanted promotions, > longer tenured GC's and in the end heap fragmentation resulting in a full > defrag gc that can take 10s of seconds. > > Defaults are there for a reason, to take care of most situations. Any > settings other than the three default Garbage Collectors (Default for > shortest time to finish, CMS for shortest pause , G1 for short pauses but > long running times) and at most a pause hint for their heuristics means > you're entering case-specific territory and should be treating it so. > > This means realistic benchmarking, profiling and comparisons between > different settings. I'd treat any JVM product or library with more than 2 > GC parameters with care, because if they need so much tweaking as their > default, you can be sure to need both a good understanding of their inner > workings and JVM memory managent as well to keep them performing in your > specific case. > > -- > 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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
which GC optimizations work better with Clojure?
GC parameters used by a lot of projects are handed down like traditions for years, even spreading to others. They're almost never re-evaluated, which means they might actually lose out on new performance improvements, or worse, might even cause performance regressions. Most parameters in the Overtone lib for instance have been the default for quite some time (ParNew GC, TLAB). Where restricting New Gen might be a good idea to reduce new gen GC latency, it can cause unwanted promotions, longer tenured GC's and in the end heap fragmentation resulting in a full defrag gc that can take 10s of seconds. Defaults are there for a reason, to take care of most situations. Any settings other than the three default Garbage Collectors (Default for shortest time to finish, CMS for shortest pause , G1 for short pauses but long running times) and at most a pause hint for their heuristics means you're entering case-specific territory and should be treating it so. This means realistic benchmarking, profiling and comparisons between different settings. I'd treat any JVM product or library with more than 2 GC parameters with care, because if they need so much tweaking as their default, you can be sure to need both a good understanding of their inner workings and JVM memory managent as well to keep them performing in your specific case. -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: which GC optimizations work better with Clojure?
It depends. CMS or G1 would be better in common cases as you said, clojure runtime has many short-lived objects. We are using G1 in your production. But sometimes you would prefer system throughput rather than GC pause time, you may try Parallel GC. 2016-04-29 19:02 GMT+08:00 Camilo Roca: > > Following this thread: > http://stackoverflow.com/questions/16695874/why-does-the-jvm-full-gc-need-to-stop-the-world > > I was wondering if anybody has some experience regarding GC optimizations > that would work better for Clojure than the default: stop-the-world > approach. > My point being that given Clojure's immutable data structures, there is a > lot of GC that is performed on young-objects which I guess could be > optimized with some GC tweaks. > > Has anybody experience with something similar? > > So far the only reference that I have of a Clojure project using such > optimizations is Overtone: > https://github.com/overtone/overtone/blob/master/project.clj > > Which scenarios do you think that call for GC tweaks in Clojure? > > -- > 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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 庄晓丹 Email:killme2...@gmail.com xzhu...@avos.com Site: http://fnil.net Twitter: @killme2008 -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
which GC optimizations work better with Clojure?
Following this thread: http://stackoverflow.com/questions/16695874/why-does-the-jvm-full-gc-need-to-stop-the-world I was wondering if anybody has some experience regarding GC optimizations that would work better for Clojure than the default: stop-the-world approach. My point being that given Clojure's immutable data structures, there is a lot of GC that is performed on young-objects which I guess could be optimized with some GC tweaks. Has anybody experience with something similar? So far the only reference that I have of a Clojure project using such optimizations is Overtone: https://github.com/overtone/overtone/blob/master/project.clj Which scenarios do you think that call for GC tweaks in Clojure? -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.