Dave wrote:
On 7/25/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
Without some information about what kind of traffic you are trying to
handle it is very tough to make recommendations. I have experience with
our traffic for blogs.sun.com, but if you are getting more traffic then
us then any advice I can give is obviously less proven.
IMHO you need more RAM for caching and possibly a full hardware refresh
including a second machine. You said yourself that the heap fills up
with Strings, likely related to velocity and hence the rendering system.
If this is the case then you need more RAM both for rendering and for
caching. We can run BSC fine on a single machine (SunFire T2000) even
when restarting everything from scratch (we actually tested this
yesterday :( ), but we have a 3.6G jvm heap and 6G of additional memory
allocated to memcached for caching, so that could be the differentiating
factor here.
I agree that JRoller.com is probably light on hardware, RAM, number of
Matts, etc. but what I'd like to understand is why this problem occurs
with Roller 3.1 but was not happening with Roller 2.0. As I understand
the situation, JRoller.com was running OK but not great before 3.1 and
now is blowing up every X number of hours. I believe Matt is running
with the very same hardware configuration, same database w/same
content, same Servlet container, etc.
I wonder what has changed to cause this problem. Since the profiler
seems to implicate Velocity, I looked at the way we used Velocity in
2.0 and the way we use it now and though we no longer use the
VelocityServlet, we do use the same Velocity property settings, the
same ResourceLoaders, etc. I can't see any significant difference.
That is definitely a good question, but a pretty large number of things
changed between 2.x and 3.x, especially in the rendering code, so it's
going to be hard to say exactly what changed to cause the problem.
It's also entirely possible that this was just the straw that broke the
camel's back and this outcome was inevitable even without the upgrade.
You said that the site was already suffering a bit before the upgrade,
so that's already not a great sign. We actually had a scenario like
this happen to us on BSC for a day or two where all of a sudden one
afternoon the site seemed to slow to a grinding halt. It turned out
that the problem was a mix of poor database queries by Roller and some
inadequate database configuration work which resulted in a bunch of our
queries becoming painfully slow once the data set had reached a certain
size.
I don't have any answers though, it's a tough situation because you are
mixing a lot of variables. I still think hardware is the best place to
start.
-- Allen
- Dave
