jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Lin" <wool...@gmail.com>
Subject Re: Monitor Results - Memory Load Percentage
Date Fri, 21 Jul 2006 12:56:04 GMT
sounds like there is a memory leak some where.  generally speaking, if a
webapp is well written, the memory percent should should a regular pattern.
I generally prefer to have the memory percent below 60%.

based on your description, it sounds like the application is either memory
hungry, or it may have a slow leak.  Your conclusion is correct.  At this
point, using a profiler is the only way to track the problem down.  the
monitor is very basic and simple, so it won't help diagnose memory leaks.

I mainly use borland optimizeIt to profile tomcat and have had good luck
with it. I hear yourkit is also a good product.

good luck

peter

On 7/21/06, Andy Dawson <andy@iti.upv.es> wrote:
>
> Hi Peter,
>
> As always thanks for your reply.
>
> I assumed there was a good reason for the choice - I did google before
> posing the question, is there a more appropriate search that might
> prevent (my) duplicate questions? My more detailed search just now
> pulled up your blog on the topic.
>
> The application that I am load testing keeps dropping out unexpectedly
> over time, I was finding that a reported memory % that continually
> bounces around 90% from beginning to the end of a test with steadily
> increasing number of threads (end being when the server stops
> responding), didn´t tell me what I expected, hence the change to my
> local set up.
>
> I deduce I should investigate using a profiler rather than tweaking the
> monitor and getting (potentially) erroneous or misleading results (due
> to local changes).
>
> Thanks & regards,
>
> Andy
>
> Peter Lin wrote:
> > The reason for using (total - free)/total is that max value is not
> > accurate.
> > the only cases where max is more useful is if someone wants to know how
> > close to Max they are and they've set an explicit Max heap.
> >
> > other people have asked about this in the past. For example, on linux or
> > solaris, if one were to use top to see the memory used by tomcat,
> > often it
> > won't match the max value. Therefore it's not accurate and doesn't
> really
> > help.
> >
> > tomcat could crash before ever reaching the max. Most of the cases
> > where I
> > see servlet container crash is a sudden spike, which ends up looking
> > like a
> > spike in jmeter tomcat monitor.  hopefully that explains the rationale
> > behind using (total - free)/total
> >
> > peter
> >
> >
> >
> > On 7/20/06, Andy Dawson <andy@iti.upv.es> wrote:
> >>
> >> Hi All,
> >>
> >> I have a simple jsp application I am currently testing and Tomcat is
> >> installed with all the defaults. After noticing that the memory load
> was
> >> always above 50% according to JMeter I wondered if this was reporting
> >> what I was expecting.
> >>
> >> With the defaults, and for low/no load, the server reports something
> >> like:
> >> Free Memory: 13300000
> >> Total Memory: 32000000
> >> Max Memory: 66600000
> >>
> >> The documentation implies, as is clear from the code, that the memory
> >> load percentage is calculated as
> >> Load = (Total - Free)/Total
> >>
> >> I was expecting it to be:
> >> Load = (Total - Free)/Max
> >>
> >> Do I understand correctly the intended meaning of server Memory Load?
> >>
> >> Thanks in advance, Regards,
> >>
> >> Andy
> >> PS. I´ve already changed the code in my install to do the above.
> >> Ref:
> >>
> http://jakarta.apache.org/jmeter/usermanual/build-monitor-test-plan.html
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message