Coldfusion JVM - Dedicated Server

[NewYorke]

I have a question regarding CF10, CFMAIL and JVM settings.

We have dedicate CF server with 16GB memory that acts as a feeder to PowerMTA (SMTP).
There is nothing else on the server - CF10 ENT only.

We send CFMAIL in a loop to app. 100,000 with content size of app. 25K.

We are spooling the mail to memory.

I was wondering what the best JVM settings would be for this config.

With 16GB - what settings would you recommend?

-Xms1024m -Xmx1024m

-XX:PermSize=1024m -XX:MaxPermSize=2048m

Also, any garbage collection settings you would add to ensure no Out Of Memory errors?

[carl type3]

Hi,

Perhaps you do well to commence some Java logging to know how much memory heap and non heap are being consumed. Garbage Collection statistics will also be know with some logging.

CF10 since update 14 support Java 8. You are likely running Java 7. So even a Java version change is an available option. Again Java logging can be a good indicator to know if version change is a good idea or not.

What sort of Java logging?

You could enable "traditional" Java logging to a log file. The log contents can be a bit hard to understand so you can pass the log file to a graphical tool to picture the heap and GC costs.

You can enable JMX and use JDK tools like Jconsole, Jvisualvm or the more recent JMC (Java Mission Control) to see real time what the heap non heap and GC overheads are.

Since you have Enterprise CF Monitor is available to you. While CFMon does not say much about non heap or GC pause time it does show some heap consumption.

Let me know if you want more details on the Java logging methods mentioned.

Generally I find CFMAIL has very little memory overhead.

HTH, Carl.

[Charlie Arehart]

But Carl, note that he said he has changed things to spool to memory, not disk. That could definitely change the memory profile.

@NewYorke, can you tell us why you are doing that? It could indeed put significant burden on heap use, at the rates you are indicating (100k mails of 25k each). Since that “spool to memory” option is relatively new (as of a couple releases ago) and not one I see used too often, I don’t know how things will work. We might presume that after each email is sent, the heap space used for it would be GCable, but it may be that if it’s all done in one CFMAIL and/or one CFML page that perhaps they would NOT be GCable until the end of the request. That would be bad at the rate you are quoting.

But why bother with it at all? Did you find that the default “spool to disk” was causing its own problem?

To be clear, I’m pretty sure the main purpose of the “spool to memory” (which is really saying “don’t spool at all”) was to give people a way to know, when they sent a cfmail, whether it was delievered (to the SMTP server) or not, synchronously, as opposed to the traditional behavior where spooling a cfmail to disk meant that the user’s request could proceed and end, and the mail would be sent on by the spooling mechanism (running in the background at a default of every 15 seconds, I believe). Then one would look at the mail folder’s undelvr directory (or CF’s mail log) to see if any emails failed to be sent to the SMTP server for some reason.

So again what’s making you choose to go this route (not spool to disk). It can’t be because you want to get synchronous confirmation of the 100k emails sent. Indeed, I’d think not spooling to disk could make the page take so long (since it DOES have to wait for each email to be sent successfully to the SMTP server).

/charlie