Wow, guys, I would offer significant caution about a lot of the assertions here.
It's NOT always true that increasing memory will improve performance. Not at all. Indeed, there are times when increasing the heap could cause MORE problems (and even just raising it from 512 to 768). It's too much to get into in a mail thread, but let me just say that if you ever get the error, "outofmemory - unable to create new native threads", that is NOT a sign that you should INCREASE the heap. Indeed, it may be an indication that you should DECREASE it (to give more space to the stack, where threads are being created and there's not enough room left because of the higher heap size). You should only increase memory if you have evidence of needing it-whether that's other (real) outofmemory errors in the CF runtime logs, or by viewing memory use in a tool like FusionReactor, SeeFusion, the CF8/9 Enterprise monitor, VisualVM, or the like. (And even two of those can mislead you: SeeFusion and the CF Monitor report the percent of used versus currently allocated memory. If you have not set min=max heap, then t may seem that the heap is "full" by their graphs when in fact it's just that you're only near the top of currently allocated memory and there's plenty more it can/will allocate when it needs it, up to the Max. FusionReactor correctly reports all three: used, allocated, and max.) And even if you do show you're starting to run low on memory, I would argue first that you should find the cause of the high memory use before raising it. Usually there's an explanation. I've helped many do that to avoid needing to increase memory (even if they could without the native thread problem.) Similarly, Ajas has described having a slow machine. I really don't agree with concluding that this has ANYTHING to do with memory. There are dozens of other explanations for a slow machine, and in my troubleshooting consulting I nearly always help people find that they are not EVEN code (or SQL) issues. They're nearly always configuration issues (or surprising and unexpected traffic, or other things). Bottom line: we in the CF world need to temper our jumping on "solutions" without diagnostics and measurements. I see WAY too many blog entries and mailing list threads where people are trading JVM tweaks-when they have not yet even proven that this is where the root cause of the problem is. Not meaning to embarrass anyone here. That's why I'm not replying specifically to anyone. It really is a bigger concern as it's so prevalent. Nor am I saying this all to drive people to use my troubleshooting consulting. I'm just saying that we need to avail ourselves of the various logs and diagnostic tools, whether built-in, enable-able, or purchasable.) In fact, to help this very issue, I am planning to start a weekly call-in web radio show which I will call CF911, to both discuss these things and take caller questions (or feedback/correction from other listeners). /charlie ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -------------------------------------------------------------
