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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > thanks for the feedback. > > > > > > > > On 8/18/05, Jonathan Oexner <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
