Tips on JVM tuning for Lucee

[Jonathan Brookins]

I thought it would be instructive if folks posted any JVM tuning tips that help Lucee performance, stability, et al.  I've tried some GC tuning settings, but they don't seem to work on the server.  Guess I need to do some more research.

[Mark Drew]

Always leave that till last. 

Start on your DB, then your code and leave that kind of tuning till last. Check out this book for more tips: 

http://www.amazon.co.uk/Apache-Tomcat-Essentials-Tanuj-Khare/dp/1849516626

Apart from increasing memory (if needed) I generally suggest that you fix as much in your app as possible before fiddling and copy and pasting settings from across the internet into your application. 

Regards

Mark Drew


develop • deploy • deliver
http://charliemikedelta.com

On 23 Jun 2015, at 16:24, Jonathan Brookins <jon.br...@gmail.com> wrote:

I thought it would be instructive if folks posted any JVM tuning tips that help Lucee performance, stability, et al.  I've tried some GC tuning settings, but they don't seem to work on the server.  Guess I need to do some more research.

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/84415e55-65d0-4f3c-9e10-77b184d74ab3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Harry Klein]

Hi Jonathan,

 

Settings sample:

 

Memory

-Xmx: 4 GB (max. 32GB)

-Xms: as Xmx

-Xss: 256K

 

Garbage Collector:

The G1 Collector seems to need more CPU and RAM – but frees more memory.
If you don’t have more than 6 GB XmX you should select the CMS Collector.

 

Java Options for JDK 7 (with CMS GC = UseConcMarkSweepGC):

…

-XX:NewRatio=4

-XX:SurvivorRatio=8

-XX:PermSize=512m

-XX:MaxPermSize=512m

-XX:+UseCompressedOops

-XX:+UseConcMarkSweepGC

-XX:+UseParNewGC

-XX:+CMSClassUnloadingEnabled

-XX:+UseCMSInitiatingOccupancyOnly

-XX:CMSInitiatingOccupancyFraction=68

-XX:+CMSScavengeBeforeRemark

-XX:+UnlockExperimentalVMOptions

-XX:+UseFastAccessorMethods

-XX:+AggressiveOpts

-XX:+DisableExplicitGC

-javaagent:D:/ApacheTomcat-7.0.25/luceelib/lucee-inst.jar (nur Lucee)

 

Java Options for JDK 8 (with G1 GC = UseG1GC):

…

-XX:+UseG1GC

-XX:+ParallelRefProcEnabled

-XX:MaxGCPauseMillis=200

-XX:InitiatingHeapOccupancyPercent=70

-XX:G1ReservePercent=15

-XX:ParallelGCThreads=20

-XX:ConcGCThreads=5

-XX:+AggressiveOpts

-javaagent:D:/ApacheTomcat-7.0.25/luceelib/lucee-inst.jar (nur Lucee)

 

-Harry

--

[Mark Drew]

Pasting things like this might not help your app BTW, it doesn’t have to be anything. It depends on how your app works. 

MD 

Mark Drew


develop • deploy • deliver
http://charliemikedelta.com

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/F5A941E045A6FE4288ABB2E3D797146FA73B604B%40SRV-DC1.contens.local.

[Matthew Stevanus]

I agree with Mark.  There are so many areas to concentrate on that will yield performance benefits that tuning the memory usage should be left for last.

Also, since every application is different, there's no silver bullet set of parameters that will make the JVM run properly for every instance.

If you're having stability issues, it's in your application or database, not in the JVM settings.  I have Railo instances running thousands of concurrent users with no issues.  The only time we ever have to restart the server or Railo is when there's a network outage that borks up the entire system.

Matt

[Jonathan Brookins]

Not having an issues, the server is just starting to be used for actual applications. I will put off worrying about any JVM performance issues until they actually arise.  I was just curious to see whether there were some good general purpose settings we could add before the server gets too busy.

Thanks for all of the replies, it is all good information to have.

[Harry Klein]

I agree with both of you - and Kai König, Mike Brunt and others mention it in every JVM tuning session:

Take care with all JVM tuning tips – you have to test your application and find YOUR perfect combination.

 

But, I was very happy years ago about all information/tuning samples I could get.

And in my opinion things got only better with JDK 8 and GC1 – before imho you HAD TO tune your JVM Settings (in big projects) in order to prevent memory leaks.

Especially if you are generating lots of classes - the default Java VM did not GC the PermGen. -XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC are very important in this case.

 

-Harry

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/46f63612-524e-46a9-b8b8-f848d9ce9783%40googlegroups.com.

[Kai Koenig]

All you you are right to some extent :)

There are lots of areas you can get easier performance gains from, mainly the database and your application.

Usually people only start looking into JVM tuning because there are issues - like long pauses or latency etc.

However that’s the wrong approach. Nearly all JVMs out there come pre-setup with non-suitable heap sizes and a high-throughput garbage collector. That might be fine if you run a small or a few small websites on a grunty server, but it will instantly produce really bad performance on large heap systems and system under high load.

The minimum what everyone who runs a web-based server on a JVM should do is:

a) set min and max memory suitable to hardware architecture (32/64 bit) and application(s) size(s) on the JVM.

b) If you have a heap larger than 2GB, change your Garbage Collector to Concurrent Mark Sweep, if you have a heap of even 6-8GB+ strongly consider G1 as an alternative to Concurrent Mark Sweep provided you’re on a late JVM 7 or a JVM 8. Both those collectors are low-pause collectors and Oracle themselves recommend them for server applications. Note: Both low-pause collectors will from experience create between 5-15% more CPU than the default collector — how much of an impact it will make depends on so many variables that it’s not worth elaborating on them on a mailing list, it’s just too much.

I would strongly advise against just blindly using what Harry has posted - not because those settings are bad, but because there are no settings that fit any random use case and using settings that are not suitable essentially can turn your performance to shit and make it even much worse than before.

Cheers

Kai

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/46f63612-524e-46a9-b8b8-f848d9ce9783%40googlegroups.com.

[Kai Koenig]

Just a quick note, Harry - UseParNewGC is obsolete because UseConcMarkSweepGC automatically uses Parallel New for the YG in Java 7.

Some of the CMS-specific arguments you’re using are quite… “esoteric” :) — have you actually tested that they make a positive difference for you?

Cheers

Kai

[Jason Barnes]

Some random guy did a good talk on this.

http://www.slideshare.net/AgentK/jvm-isyourfriend

:D

[Harry Klein]

Hi Kai,

 

>> Just a quick note, Harry - UseParNewGC is obsolete because UseConcMarkSweepGC automatically uses Parallel New for the YG in Java 7.

 

Thanks for your note, but are you sure about that?

See :

http://www.fasterj.com/articles/oraclecollectors1.shtml

(Garbage Collectors Available In JDK 1.7.0_04)

…

The full list of possible GC algorithm combinations that can work are:

Command Options*	Resulting Collector Combination
-XX:+UseSerialGC	young Copy and old MarkSweepCompact
-XX:+UseG1GC	young G1 Young and old G1 Mixed
-XX:+UseParallelGC -XX:+UseParallelOldGC -XX:+UseAdaptiveSizePolicy	young PS Scavenge old PS MarkSweep with adaptive sizing
-XX:+UseParallelGC -XX:+UseParallelOldGC -XX:-UseAdaptiveSizePolicy	young PS Scavenge old PS MarkSweep, no adaptive sizing
-XX:+UseParNewGC	young ParNew old MarkSweepCompact
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC	young ParNew old ConcurrentMarkSweep**
-XX:+UseConcMarkSweepGC -XX:-UseParNewGC	young Copy old ConcurrentMarkSweep**
*All the combinations listed here will fail to let the JVM start if you add another GC algorithm not listed, with the exception of -XX:+UseParNewGC which is only combinable with -XX:+UseConcMarkSweepGC
**there are many many options for use with -XX:+UseConcMarkSweepGC which change the algorithm, e.g. -XX:+/-CMSIncrementalMode - uses or disables an incremental concurrent GC algorithm -XX:+/-CMSConcurrentMTEnabled - uses or disables parallel (multiple threads) concurrent GC algorithm -XX:+/-UseCMSCompactAtFullCollection - uses or disables a compaction when a full GC occurs

 

-Harry

[Kai Koenig]

Yup, I'm sure - just look in the table right below the one you quoted on the website you linked to :)

Kai

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/F5A941E045A6FE4288ABB2E3D797146FA73B62EF%40SRV-DC1.contens.local.

[Harry Klein]

J

(Sah den Wald vor lauter Bäumen nicht)

 

-Harry

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/F80F1B73-5E46-4AF5-8F8F-99E8D935A007%40gmail.com.

[Paul Klinkenberg]

Just so you know, Kai is always right. Always. ;)

Paul

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/F5A941E045A6FE4288ABB2E3D797146FA73B635A%40SRV-DC1.contens.local.

[michae...@arcor.de]

Good luck convincing Diane of that. ;)

[Kai Koenig]

Really - that's what it's come to? Discussing my marriage on a mailing list? :)

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/61b6fd7b-f4ff-4775-b1a8-0ea005e4437f%40googlegroups.com.

[michae...@arcor.de]

Nope, just reminding him that even you are still human and have to answer to "a higher power". ;)