Changing the Heap Sizes in the Coldfusion Administrator
Here's a "gotcha" tip. I have a dev server that had 512 megs of RAM on it. I had the JVM heap sizes configured at 256 meg minimum and 384 meg maximum. Today I added some memory to bring it up to 1 gig. I wanted to change the minimum heap to 512 and the maximum heap to 768. Naturally I set both of them to these new values and hit "submit". I got an error that the "minimum" cannot exceed the maximum. Apparently, the code takes care of minimum first. That means it took my value of 512 and compared it to the "old" maximum value of 384 - causing the error.
To fix this I had to set each value independently - starting with the max value. I set the max value to 768 without touching the Min value. Then I set the min value. I thought that was the end and I went happily to restart the CF service to implement my changes. Naturally the service wouldn't start. I examined the coldfusion-err log in the and it said that I could not start the JVM because I was using conflicting garbage collection switches.
Indeed I had change GC type based on some excellent tips from robi sens blog (from UseParallelGC to UseConcMarkSweepGC). Due to the error (I'm guessing) the system had added the UseParallelGC back into my jvm.config file.
So, if you are going to use the cold fusion admin ap to make JVM changes make sure and backup your jvm.config file (found in the runtime/bin directory on a standard installation).
5 Comments
-
Yes, I believe the CF Admin automatically sets the GC strategy to UseParallelGC when it modifies the jvm.config. Modifying the config thru the admin is fine as long as you're only changing basic values like heap sizes etc. Once you get into serious tweaking of the settings, you need to edit the jvm.config manually. -
Sean - Thanks for the information. I have been editing it manually of late. But if your theory is correct, why did it sort of "combine" the 2 sets of JVM arguments? It borrowed my original GC setting - (Concurrent mark sweep) and added the parrallel GC - generating an error that "you have 2 conflicting GC settings". I would have expected it to sort of "go back" to the default installation JVM arguments - yes?
By the way, the error message I referenced was a thrown CF error - not a validation message. I wasn't clear about that. -
It combines them because it "doesn't know" what args you've added - but it does make the assumption you won't change the basic GC strategy because it "knows" it needs to set it to UseParallelGC (as opposed to letting it default) in order to get better overall performance.
It's one of those classic tradeoffs in CF between ease of use (and not requiring people to know too much) and low-level power.
You can do a certain amount of stuff with the CF Admin but not everything. In order to handle the GC switches correctly it would have to expose that explicitly in the Admin - not something most CF administrators need to deal with. -
Frankly I hate using the CFAdmin for this stuff because it hides important information as well as I have had problems using the CFAdmin. For example the CFMX 7 admin corrupts your jvm.config with settings that can cause it to fail to restart or perform poorly over time.
I would rather have the CFAdmin expose all the information to me with contextual warrings or not at all and just edit the file directly. -
Robi,
Yes... that's a subject of another blog post of mine :)
http://mkruger.cfwebtools.com/index.cfm?mode=alias...
Sites to Watch
Aggregators
RSS
