 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
11 messages in org.apache.roller.devRe: JRoller Blows up with Roller 3.1| From | Sent On | Attachments |
|---|---|---|
| Matthew Schmidt | Jul 25, 2007 7:23 am | |
| Anil Gangolli | Jul 25, 2007 8:38 am | |
| Matthew Schmidt | Jul 25, 2007 8:40 am | |
| Matthew Schmidt | Jul 25, 2007 8:40 am | |
| Matthew Schmidt | Jul 25, 2007 8:41 am | |
| Allen Gilliland | Jul 25, 2007 9:17 am | |
| Dave | Jul 25, 2007 9:48 am | |
| Allen Gilliland | Jul 25, 2007 11:20 am | |
| henr...@gsa.gov | Jul 25, 2007 12:23 pm | |
| Dave | Jul 26, 2007 8:00 am | |
| henr...@gsa.gov | Jul 26, 2007 8:42 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: JRoller Blows up with Roller 3.1 | Actions... |
|---|---|---|
| From: | Allen Gilliland (alle...@sun.com) | |
| Date: | Jul 25, 2007 11:20:46 am | |
| List: | org.apache.roller.dev | |
Dave wrote:
On 7/25/07, Allen Gilliland <alle...@sun.com> 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