Charlie:
I have seen those errors before and would in the past, adjust both
java Vm settings and heap size in the BD admin console, as well as
MySQL settings. I did that over many months a few years back. Using
the same system today.
The settings I use now yielded the best results - no errors, faster
execution times, no crashes, low cpu usage. However....
I do agree with you that there are often many other issues to solve.
In fact, thinking back to our meeting back in 2004 when you helped me
set up BD on my XServe and thus made me a BD fan forever, it was
obvious then that there were other issues to solve and that BD/CF was
not the issue.
Over the past 5 years, BD 6 has proven to be very reliable and robust
and I generate a fair number of page views on a daily basis.
Yesterday, for example, 79,000 CF pages generated - granted 72,000
were spider/crawlers and only 7,000 were user page views. But as far
as the data execution, a page load is a page load. And that does not
include the 10,000 RSS feeds generated on the fly. So...
When I've run into problems in the past, it's generally been either an
SQL statement that I did not think through, or a server issue - mail
problems, FTP break in attempt, etc.,
All that being said, over the pst 5 years, we've taken pains to
simplify the roles of the server itself so that it is not doing 100
various things. DNS, a single mail account, a very few select number
of FTP users, firewall and then web. That's it. No custom install
stuff, very strict clean OS. And with that, the settings I have used
for BD (CF) remain the best for my situation. 4 GB to MySQL, 2 GB to
BD w/1GB heap.
I say "best" because I sleep at night and don't have errors, excessive
CPU or other crazy issues. Perhaps someone could tweak it more. But
it's a proven set up.
_____________________
Derrick Peavy
[email protected]
“Innovation distinguishes between a leader and a follower.” -Steve Jobs
"A good deal that used to be a great deal, is not nearly as good as an
awful deal that was once a horrible deal." - Dan Gilbert, http://bit.ly/8gUruX
_____________________
On Jan 14, 2010, at 7:18 PM, Charlie Arehart wrote:
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 FusionLink
-------------------------------------------------------------
