tag:blogger.com,1999:blog-3857007129715168662.post4607633193489065762..comments2022-11-17T10:08:48.880+02:00Comments on Le Café Performant: A Blog On Java Performance: JVM Params Everyone Should Have in Production Lifeyhttp://www.blogger.com/profile/10586718302147663938noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-3857007129715168662.post-80923403768828089192014-03-16T20:03:49.962+02:002014-03-16T20:03:49.962+02:00This comment has been removed by the author.Lifeyhttps://www.blogger.com/profile/10586718302147663938noreply@blogger.comtag:blogger.com,1999:blog-3857007129715168662.post-5764003064372285582014-03-16T20:03:47.265+02:002014-03-16T20:03:47.265+02:00"Must have" is related to my point of vi..."Must have" is related to my point of view. Of course you can disagree with that. There is a huge number of parameters that one can use for his JVM. For each one of the parameters stated in the above list I have a strong reason to use add it. The flags related to JMX remote monitoring the flags related to GC logging the HeapDumpOnOOM etc. <br />Regarding PermGen size Most of the projects I have seen require to increased the permgen size. Stating it is like declaring that you acknowledge that there is such a space and you know how much of it you need :) Lifeyhttps://www.blogger.com/profile/10586718302147663938noreply@blogger.comtag:blogger.com,1999:blog-3857007129715168662.post-22875045804329931552014-03-14T15:04:01.936+02:002014-03-14T15:04:01.936+02:00It is quite a strong statement: "must have&qu...It is quite a strong statement: "must have". <br /><br />You should actually use as few JVM flags as required. So if you know, that default PermGen size is enough for you, why add the extra flag ?<br /><br />JVM flags in startup scripts have this weird tendency to stick around much longer than actually needed. They often become obsolete when new versions of JVM are available.<br /><br />But I do STRONGLY agree on all the GC flags. They should always be there so we have logs available from when the problem occured. Adding them after one has happened is not a good practice.<br /><br />Also some people say that they don't enable GC logging because of performance reasons... well, I would just direct them to Kirk Pepperdine's JVM Tunning workshop :)Anonymoushttps://www.blogger.com/profile/00946072483901797116noreply@blogger.comtag:blogger.com,1999:blog-3857007129715168662.post-70897674279040438312013-10-23T00:59:46.394+03:002013-10-23T00:59:46.394+03:00A whole bunch of GC params -
http://orangemile.b...A whole bunch of GC params - <br /><br />http://orangemile.blogspot.com/2013/10/gc-parameters.htmlAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-3857007129715168662.post-15963900313080499852013-09-26T14:53:29.155+03:002013-09-26T14:53:29.155+03:00I agree, Usually servers are behind firewall so th...I agree, Usually servers are behind firewall so the port will be blocked anyway. I doubt that any enterprise will open a port in a firewall for JMX monitoring. So it is pointless to go through the hassle of encrypting and authenticating.... <br />Lifeyhttps://www.blogger.com/profile/10586718302147663938noreply@blogger.comtag:blogger.com,1999:blog-3857007129715168662.post-67770001786415140312013-09-25T23:58:36.524+03:002013-09-25T23:58:36.524+03:00You should be careful to only disable JMX authenti...You should be careful to only disable JMX authentication if you're exposing JMX on a non-public interface/port. Of course this can be addressed with firewalling.Anonymoushttps://www.blogger.com/profile/15613912461272350420noreply@blogger.com