jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Oexner <jonathan.oex...@gmail.com>
Subject Re: Tomcat monitor memory load calculation
Date Fri, 19 Aug 2005 15:01:47 GMT
Okay, I have no desire to start (continue?) a flame war here.  I
personally have a need to see the actual memory usage of my
application, to check for leaks.  I thought it might be a common need,
and since I'd already written the code, I might as well "give back".

Yes, I know how Java "memory leaks" work.  In web apps, they're
generally when someone binds a large object (or many small ones) to
app context, or to a background processor thread that doesn't die in a
timely fashion.  I tend to first worry about the memory usage of my
application before I start blaming the system heap allocation.

I've been writing Java web apps since before JSP's, before the term
J2EE was coined, back when we wrote 1000-line Servlets and we LIKED
it.  ;)  I've used many other Java stress-testing and profiling tools.
 My current employer is too cheap to buy us a commercial product, so
I'm using JMeter instead.

What I sent was a user request.  Hostility to user requests affects
usability and prevents free software from fulfilling its potential. 
This is the last you'll hear from me on the matter.


On 8/18/05, Peter Lin <woolfel@gmail.com> wrote:
> Here is an article that might provide some useful information.
> 
> http://www.atg.com/portal/myatg/developer?paf_dm=full&paf_gear_id=1100010&detailArticle=true&id=9606
> 
> Also keep in mind that other JVM like JRockit do not have PermGen for
> static classes. So things like setting PermGen do not apply to
> JRockit. IBM's JDK also handles GC a little differently.
> 
> it's actually very common to get OOME, even though the system has
> plenty of memory. I've seen cases where the max heap is set to 1GB,
> but tomcat got OOME because the JVM couldn't increase the heap fast
> enough. these kinds of cases are typically 3-5x increase in load.
> 
> peter
> 
> 
> 
> On 8/18/05, Jonathan Oexner <jonathan.oexner@gmail.com> wrote:
> > My concern with the current used /current heap line is that, if the VM
> > decides to increase the heap size, you can't tell by looking at the
> > line whether heap size went up, or the GC freed up some memory.
> >
> > The rationale behind using the max heap size as the denominator is
> > just so that the memory used line depends *only* on the amount of
> > memory in use (well, that and the *max* heap size, which is constant
> > for our purposes).  You can see the absolute heap usage.  It has the
> > added benefit that both the heap size and the heap usage are on the
> > same scale, which means that you can see how close the memory usage
> > has to get before the JVM decides to grow the heap.
> >
> > Try it out.  You might like it.  ;)
> >
> > On 8/18/05, Peter Lin <woolfel@gmail.com> wrote:
> > > yeah, the load line is totally synthetic. honestly, I don't know which
> > > approach is best. I tend to think of things a certain way, which is
> > > based on work experience. I think adding an additional line might be
> > > good. what about
> > >
> > > current used /current heap
> > > current heap / max heap
> > >
> > > for what I do, the heap rbehavior is a better indication of
> > > application performance. under constant load, the line would show a
> > > regular pattern.  A poorly written app would show erractic heap usage,
> > > which indicates a potential problem.  For example, I tend to profile
> > > my webapps for 1million requests and see if the thread and memory
> > > usage reach a regular pattern after a few hours.  If it doesn't, I
> > > profile it with OptimizeIt and track down the issue. I probably won't
> > > have time to work on it this week, but next weekend I may have time.
> > >
> > > peter lin
> > >
> > >
> > >
> > > On 8/18/05, Jonathan Oexner <jonathan.oexner@gmail.com> wrote:
> > > > Hi Peter,
> > > >
> > > > It seems to me that we're trying to force this one status line to do 2
> > > > jobs.  Maybe we need a usage line (current usage / max heap) *and* a
> > > > current heap line (current heap / max heap).  Coincidentally, the
> > > > "Load" line seems a little, umm, "synthetic" anyway, so maybe we could
> > > > swap it out and add a line for heap size.  When the yellow line tries
> > > > to cross the blue line, your app will flatline.  ;)
> > > >
> > > > I'm actually graduated from WPI (note the "alum"), and using JMeter to
> > > > earn my keep from the Man.
> > > >
> > > > On 8/18/05, Peter Lin <woolfel@gmail.com> wrote:
> > > > > thanks for the feedback.
> > > > >
> > > > > On 8/18/05, Jonathan Oexner <jonathan.oexner@gmail.com> wrote:
> > > > > > Hi all,
> > > > > > I'm just getting started with webapp performance testing with
JMeter,
> > > > > > and I noticed the bug mentioned in the thread 'Possible bug
in monitor
> > > > > > results listener' from late last year, still present in release
2.0.3
> > > > > > .  I downloaded the nightly 2-1.20050812, only to find that
the bug
> > > > > > "fix" in CVS is still a little off.  The memory usage that most
people
> > > > > > want to see (IMHO) is:
> > > > > >
> > > > > > current usage / maximum available
> > > > > >
> > > > > > as opposed to:
> > > > > >
> > > > > > current usage / current heap size
> > > > > >
> > > > > >
> > > > > > They don't really care what the JVM is doing to the current
heap size;
> > > > > > they just want to know the absolute usage, and how close the
are to an
> > > > > > OutOfMemoryError.  Additionally, since the *currently allocated*
heap
> > > > > > size will change whenever the JVM decides to change it, using
it for
> > > > > > the denominator makes it very hard to get an idea of the actual
usage.
> > > > > >  I'm much too lazy to submit an actual patch, but in
> > > > > > $JMETER_HOME/src/monitor/components/org/apache/jmeter/monitor/util/Stats.java
> > > > > > , I changed the two methods below, and the results make a whole
lot
> > > > > > more sense this way.
> > > > >
> > > > > In practice this is not true. In most cases, a server will crash
> > > > > before it reaches the max heap size. I tested tomcat about 2 dozen
> > > > > times with a wide variety of loads. I actually started with the
> > > > > assumption that max heap was better, but after I ran some tests,
it
> > > > > became apparent that wasn't true.
> > > > >
> > > > > if you were to profile tomcat with verbose GC you would see that
often
> > > > > an application runs out of memory because the JVM is unable to resize
> > > > > the heap fast enough. this typically happens with a sudden traffic
> > > > > spike occurs. Under steady constant or semi-constant load, current
> > > > > usage / current heap is also more accurate. Say for example I set
my
> > > > > max heap to 512Mb. If constant load uses  200, using the max heap
> > > > > won't tell me much. In fact it will give me a false sense of security.
> > > > >
> > > > > also, using the current used / current heap lets you see how the
JVM
> > > > > is resizing the heap and indicates if there is a memory. Several
> > > > > tomcat developers use Jmeter monitor for that purpose and so do I.
 If
> > > > > you don't believe, I would suggest changing it and run 20-30 tests
> > > > > with varying request rates and thread count.
> > > > >
> > > > > I noticed you're attending Worcester Polytech. Are you doing this
for a degree?
> > > > >
> > > > > peter lin
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Mime
View raw message